method and apparatus for traffic routing and path optimization for point-to-point communications

专利摘要:
Application function (AF) influenced by routing for point-to-point communications (P2P) is provided. The main network elements correlate the PDU sessions and optimize the UP path for point-to-point traffic. The selection, re-selection, configuration or reconfiguration of UP can be performed in support of P2P traffic routing. P2P traffic between a pair of UEs is routed or rerouted over a bridge. The bridge can be established between the first UP and the second UP, and / or between the associated RAN nodes. One or more application functions can be added along the bridge path. A policy control function (PCF) directs the underlying resources to route P2P traffic across the bridge, for example, in response to an AF trigger. A session management function (SMF) directs the underlying resources to configure or reconfigure user plan data paths to route P2P traffic across the bridge. The first and second SMFs of the first and second UPs can cooperate to establish the desired traffic routing. One or more UPFs can be configured to support the detection of P2P traffic.
公开号:BR112020009916A2
申请号:R112020009916-3
申请日:2018-11-15
公开日:2020-11-03
发明作者:Xu Li；Ngoc Dung Dao；Hang Zhang
申请人:Huawei Technologies Co., Ltd.；
IPC主号:

专利说明:

[0001] [0001] The present application claims priority from U.S. Non-Provisional Patent Application No. 16 / 185,795 filed on November 9, 2018, which claims priority from US Provisional Patent Application No. 62 /
[0002] [0002] The present invention relates to communication networks such as 5th generation (5G) networks, and, in particular, to a method and apparatus for traffic routing and path optimization for point-to-point communications on a network , for example, which can be responsive to the influence of an application function (AF). BACKGROUND
[0003] [0003] Point-to-point communication refers to communication between two end devices, such as two user devices (UEs), in this document referred to as UE-1 and UE-2. In a conventional example, UE-1 initiates a packet data unit (PDU) session establishment procedure involving an application server (AS), and uses the established PDU session to send application traffic. Based on application traffic from the UE-1, the AS identifies the target device UE-2 and triggers another PDU session establishment procedure to communicate with the UE-2. Traffic from the UE-1 is sent in the uplink (UL) direction through the first PDU session and then to the UE-2 in the downlink (DL) direction through the second PDU session.
[0004] [0004] For unstructured PDUs, the AS correlates the two PDU sessions and routes point-to-point traffic between the two UEs. For IP or Ethernet PDU, the two PDU sessions are correlated at the transport layer. For example, point-to-point traffic can be handled by routing intelligence into the appropriate anchor user plan functions (UPFs). User plans (UPs) for the two PDU sessions are established and maintained independently, and this can lead to inefficiencies, such as inefficiencies in the UP path.
[0005] [0005] Therefore, there is a need for a method and apparatus for routing traffic in point-to-point communications on a network that obviates or mitigates one or more limitations of the state of the art.
[0006] [0006] This background information is provided to reveal information considered by the applicant to be of possible relevance to the present invention. No admission is necessarily intended, nor should it be interpreted, that any of the foregoing information constitutes state of the art against the present invention. SUMMARY
[0007] [0007] An objective of the modalities of the present invention is to provide a method and apparatus for routing traffic influenced by Application Function (AF) for point-to-point (P2P) communications on such a network. Network elements are used to correlate PDU sessions and to optimize the UP path for point-to-point traffic. UP path selection or reselection, UP path configuration or reconfiguration, or both, can be performed in support of P2P traffic routing.
[0008] [0008] Modalities of the present invention provide a control function (such as a policy control function) associated with a main network portion of a communication network, the control function including a processor operationally coupled to memory and an interface network. The control function is configured to receive a message indicating a correlation between two or more PDU sessions, for example, for joint user plan (UP) management. The control function is further configured, in response to the message, to transmit, to one or more management functions (such as session management functions), an instruction that causes the respective UP paths of at least one of the two or more PDU sessions are selected or re-selected according to the correlation between the two or more PDU sessions.
[0009] [0009] The modalities of the present invention provide a method for controlling user plane (UP) paths in a communication network. With reference to FIG. 23, method 2300 includes operations by a control function associated with a portion of the main network of the communication network. The control function comprises or, otherwise, uses a processor operationally coupled to memory and to a network interface. The method includes receiving a message 2310 requesting a correlation between two or more PDU sessions, for example, for joint user plan (UP) management. The method also includes, in response to the message, transmitting 2320, for one or more management functions, an instruction that causes the respective user plan (UP) paths of at least one of the two or more PDU sessions to be selected. or re-selected according to the correlation between the two or more PDU sessions.
[0010] [0010] In the modalities, the correlation is indicative of one or more of the following: the two or more PDU sessions are part of the same multicast (“multicast”) or non-multicast (“anycast”); the two or more PDU sessions correspond to peer sessions in peer-to-peer communication; the two or more PDU sessions are part of the same PDU group session; and the two or more PDU sessions correspond to the interaction with a common application.
[0011] [0011] In the modalities, the instruction includes a first instruction for one or more of the following, for example, in order to create a bridge between the PDU sessions: Make at least one PDU session include, in a UP path , a user plan function which is also included in another UP path of at least one of the two or more PDU sessions. Make at least one PDU session include, in a first UP path of the same, a first user plan function which is communicatively coupled to a second user plan function, the second user plan function being included on another UP path from another of the two or more PDU sessions. Make at least one PDU session connect to an application location which is also connected to at least one of the two or more PDU sessions.
[0012] [0012] The control plan function can select or reselect the user plan function, the first and second user plan functions, the application function, or the first and second application functions, and the instruction may include policy rules to be implemented by one or more management functions. Alternatively, the instruction can cause the management functions to perform the selection or re-selection.
[0013] [0013] The modalities of the present invention provide a network function (or application function) including a processor operationally coupled to memory and a network interface. The network function is configured to transmit a message to a control function, the message indicating a correlation between two or more PDU sessions and instructing the control function to make the respective UP paths of at least one of the two or more PDU sessions are selected or re-selected according to the correlation. The network function is further configured to receive a response from the control function message. In the modalities, the network function is further configured to identify the correlation between two or more PDU sessions before transmitting the message to the control function.
[0014] [0014] In the modalities, the correlation is identified by the network function, for example, as reflecting an existing property of the PDU sessions. As a result of the identified correlation, the network function can instruct or request that the control function adjust the UP paths in a way that is responsive to the identified correlation. In the modalities, the message includes an indication of whether or not the UP paths of the two or more PDU sessions should be connected via an application location. In the modalities, the message includes an indication of a primary PDU session of the two or more PDU sessions or of a primary UE of the two or more PDU sessions.
[0015] [0015] The modalities of the present invention provide a method, for a network function including a processor operationally coupled to memory and a network interface. With reference to FIG. 24, method 2400 includes transmitting a message to a control function 2420, the message indicating a correlation between two or more PDU sessions and instructing the control function to cause the respective UP paths of at least one of the two or more PDU sessions are selected or re-selected according to the correlation. The method also includes receiving a 2430 response to the control function message. The method may further include identifying a 2410 correlation between two or more PDU sessions before transmitting the message to the control function.
[0016] [0016] The modalities of the present invention provide a session management function (SMF) associated with a main network and managing a first PDU session. SMF includes or otherwise uses a processor operationally coupled to memory and a network interface. The SMF is configured, in response to a trigger of a policy control function (PCF), a user plan function (UPF), or a second SMF, to target resources (for example, by configuring a UPF or another underlying resource) to handle data traffic that forms part of a first PDU session and corresponds to a "correlated" traffic flow (such as a point-to-point traffic flow), the first PDU session associated with a first user plan managed by SMF. The manipulation of data traffic may include the detection of data traffic. The SMF is further configured to direct more resources to handle the data traffic that forms part of a second PDU session and corresponds to the correlated traffic flow, the second PDU session associated with a second user plan managed by the second SMF. The direction can be direct, for example, configuring another UPF, or indirect, for example, instructing the second SMF to configure the other UPF. The correlated traffic flow is routed through the first user plane and the second user plane. Indirectly targeting additional underlying resources may include passing an instruction to the second SMF to have the second SMF configure the additional underlying resources.
[0017] [0017] In the modalities, the correlated traffic flow is a point-to-point traffic flow. In the modalities, directing resources or additional resources comprises the configuration of a user plan function (UPF).
[0018] [0018] In the modalities, directing additional resources comprises transmitting an instruction to the second SMF to make the second SMF configure the additional resources. In other embodiments, the instruction is one or more of the following: add a new user plan role to the second user plan; remove an existing user plan role within the second user plan; move another existing user plan role from the second user plan; and reconfigure the traffic routing behavior of an indicated end point of a bridge that connects the user plan function. Additionally or alternatively, the SMF can be further configured to identify the second SMF using a received SMF identifier or address, an indication from the PCF, an indication from a unified data management function.
[0019] [0019] In the modalities, the SMF is still configured to receive, from the second SMF, information about the second PDU session, the referred information comprising some or all: identification information for the second PDU session; user plan information for the second PDU session; context information for the second PDU session.
[0020] [0020] In modalities, the correlated traffic flows between the first user plan and the second user plan through a bridge comprising one or more of: a pair of user plan functions (UPFs) communicatively coupled, each associated with a respective PDU session other than the first PDU session and the second PDU session; a UPF shared by the first PDU session and the second PDU session; a pair of application locations communicatively coupled each associated with a respective PDU session other than the first PDU session and the second PDU session; and a common application location shared by the first PDU session and the second PDU session.
[0021] [0021] Correlated traffic can flow between the first user plane and the second user plane through a bridge comprising one or more of: a pair of user plane functions (UPFs) communicatively coupled, each associated with a respective PDU session other than the first PDU session and the second PDU session; a UPF shared by the first PDU session and the second PDU session; a pair of communicatively coupled application locations, each associated with a different one from the first PDU session and the second PDU session; and a common application location shared by the first PDU session and the second PDU session.
[0022] [0022] The modalities of the present invention provide a method for operating a session management function (SMF) associated with a main network and managing a first PDU session. SMF includes or otherwise uses a processor operationally coupled to memory and a network interface. With reference to FIG. 25, method 2500 includes, by SMF and in response to a 2505 trigger of a policy control function (PCF), a user plan function (UPF) or a second SMF: direct 2510 resources to handle data traffic which forms part of a first PDU session and corresponds to a correlated traffic flow, the first PDU session associated with a first user plan managed by SMF. The method also includes directing 2520 additional resources to handle the data traffic that forms part of a second PDU session and corresponds to the correlated traffic flow, the second PDU session associated with a second user plan managed by the second SMF. The correlated traffic flow is routed through the first user plane and the second user plane.
[0023] [0023] In some embodiments, a correlation between multiple PDU sessions indicates that the end device of at least one of the PDU sessions is communicating with the end device of at least one of the PDU sessions. In some embodiments, implementing multiple PDU sessions according to a correlation between them includes routing traffic from one PDU session to another via a bridge, which can be a bridge between UPFs. The bridge can be on the main network or between radio access nodes, and can bypass AF. In some embodiments, implementing multiple PDU sessions according to a correlation between them additionally or alternatively includes determining the UP paths of the multiple PDU sessions together, for example so that the UP paths are optimized together. Optimization can be performed to facilitate efficient communication between different end users from different PDU sessions. The UP paths can be linked or connected directly or through an application location, for example, instantiated on the main network.
[0024] [0024] According to several modalities, P2P traffic between a pair of UEs is routed or rerouted through a bridge entity. P2P traffic flows between a first UE (EU-1) associated with a first user plan (UP) and a second UE (EU-2) associated with a second UP. In the present disclosure, the terms "UP" and "UP path" are used interchangeably. An application server (AS) is operationally coupled to the first and second UPs. Instead of P2P traffic flowing through the AS or through the anchor UPFs of the two UPs, the bridge is established between a component of the first UP and a component of the second UP, and P2P traffic is detected and routed through the bridge. The bridge can be implemented using traffic handling behaviors from the first and second UPs, including P2P traffic identification and traffic routing. A bridge can also be described as a connection in several ways.
[0025] [0025] The bridge entity can be a bridge communication link over which P2P traffic is routed or a common UPF. In the case of a common UPF, the first and second UP paths share the common UPF, and P2P traffic is routed through the common UPF between UE-1 and UE-2.
[0026] [0026] According to other modalities, the bridge can be established between a radio access network node (RAN) located between one of the UEs and its associated UP and a component of the UP associated with the other UE. According to other modalities, the bridge can be established between a RAN node located between the first UE and the first UP, and a RAN node located between the second UE and the second UP.
[0027] [0027] Some embodiments of the present invention provide the direct connection of PDU sessions via bridge. The paths of the connected PDU sessions can be optimized together. Some modalities provide indirect connection of PDU sessions through one or more application servers. In this case, the application server can be arranged or selected along the P2P path. This is accomplished when P2P communication requires support from an application server. The paths of the connected PDU sessions and the application server placement or selection can be optimized together. Path optimization can include configuring P2P paths in the user plan to support traffic routing.
[0028] [0028] According to several modalities, a policy control function (PCF) is configured, configured to configure a session management function (or alternatively other underlying resources) to route P2P traffic through a bridge entity. The PCF can operate in response to a trigger or request for an application function (AF) associated with an AS.
[0029] [0029] According to various modalities, a session management function (SMF) is provided, configured to configure the features of the underlying user plan function to establish, configure or reconfigure data paths of the user plan, so that the P2P traffic is routed through a bridge entity. A first SMF associated with the first UP, and a second SMF associated with the second UP can cooperate to establish the desired traffic routing. SMF may operate in response to PCF direction, configuration, instruction, policies or rules. Based on the policies provided, SMF can determine the P2P path and configure the associated UPFs to define the P2P path. The configuration or reconfiguration of the UP data paths may include (re) configuring the connection (or tunnels) between UPFs. The SMF can also configure or reconfigure the traffic routing behavior of selected UPFs (for example, in UL CL, BP and UPF anchor).
[0030] [0030] According to various modalities, a system is provided comprising plural functions, such as AF, PCF, SMF, UPF, etc., which are configured cooperatively to route P2P traffic through a bridge entity. Each of the functions can operate as described above or elsewhere in this document. The PCF can interact with one or more SMFs, as described elsewhere in this document, to update policies to support P2P bridge configuration. Multiple SMFs, such as a source SMF and a target SMF, can interact as described elsewhere in this document to cooperatively configure a P2P bridge.
[0031] [0031] Several embodiments of the present invention thus provide a mechanism that correlates two PDU sessions to handle P2P traffic. An AF request for handling P2P traffic (which can cause two PDU sessions to correlate to establish a P2P path between your user plans) can be issued. One or more UPFs can be configured to support the detection of P2P traffic, for example, based on the AF request. In some modalities, the configuration is performed (or directed) by an SMF. The UPF configuration can cause the UPF to detect the P2P traffic of interest (according to the P2P traffic detection configuration) and notify an associated SMF. One or more SMFs are configured to determine and configure P2P paths, for example, in response to a notification from an associated UPF. If the two PDU sessions are served by the same SMF, only one SMF is involved; if they are served by two different SMFs, two SMFs may be involved. P2P paths involve a bridge connection between two UPs to support the forwarding of P2P traffic. According to various modalities, methods associated with the operation of the above components are provided, individually or in combination.
[0032] [0032] In some modalities, the SMF that manages the PDU session configures a UPF (for the UP path of the same PDU session) to perform the detection of P2P traffic. The UPF can be an anchor UPF, an UL classifier (UL CL), or a BP (branch point), for example. The UPF, operating according to the configuration, detects P2P traffic and notifies the SMF.
[0033] [0033] In accordance with the modalities of the present invention, a policy control function (PCF) associated with a main network is provided, the PCF using a processor operationally coupled to memory and to a network interface and configured for: in response to a request from an application function (AF) or other entity, communicate with one or more session management functions (SMFs) to configure its traffic handling policies, where the request refers to at least a first session of PDU and a second PDU session, the first and second PDU sessions handling a common point-to-point traffic flow (P2P), the first PDU session corresponding to the PDU traffic in a first portion of the core and a first portion of the radio access network, the second PDU session corresponding to the PDU traffic in a second portion of the core and a second portion of the radio access network, and in which, through this configuration, the traffic manipulation configure the underlying resources to cause the flow of common point-to-point traffic to cross a bridge between: the first portion of the core or the first portion of the radio access network; and the second portion of the core or the second portion of the radio access network. The AF request can be relayed through an NEF. In the relayed request, the NEF can translate or map the information in the request to information that the PCF can use directly. Traffic handling policies can be provided to one or more SMFs that are managing at least one of the two PDU sessions, which configure the UPF (s) in the UPs of the two PDU sessions to cause traffic P2P cross a bridge entity. The bridge entity can be a bridge link defined between the final UPFs for each of the UPs or a bridge UPF shared by the UPs.
[0034] [0034] In some of these modalities, the one or more SMFs comprise a first SMF to manage the first PDU session, and a second SMF to manage the second PDU session. In some embodiments, the first PDU session is associated with a first user plan and the second PDU session is associated with a second user plan. In some embodiments, AF is associated with an application server, traffic manipulation policies cause point-to-point traffic flow to bypass the application server, and control messages associated with point-to-point traffic flow common point-to-point are routed towards the application server. The PCF can also be configured to notify the AF after the implementation of traffic manipulation policies.
[0035] [0035] In accordance with embodiments of the present invention, a method is provided for operating a PCF in the manner described above.
[0036] [0036] In accordance with the modalities of the present invention, a session management function (SMF) is provided associated with a main network and managing a first PDU session, SMF using a processor operationally coupled to memory and a network interface. and configured to: in response to a traffic manipulation policy change or a trigger of a policy control function (PCF), a user plan function (UPF) or another entity (for example, NEF), configure a UPF (or other underlying resources) to detect and manipulate data traffic that forms part of the first PDU session and corresponds to a specified point-to-point traffic flow in a specified way, where the point-to traffic flow -point crosses at least one UP of the first PDU session and one UP of the second PDU session, the first PDU session corresponding to the PDU traffic in a first portion of the core and a first portion of the access network by radio (a first UP path), the second PDU session corresponding to the PDU traffic on a second portion of the core and a second radio access network portion (a second UP path), in which the specified manner causes that the flow of point-to-point traffic crosses a bridge between: the first portion of the nucleus or the first portion of the radio access network; and the second portion of the core or the second portion of the radio access network.
[0037] [0037] In some of these modalities, a second SMF is associated with the core and manages the second PDU session, and the SMF is further configured to cooperate with the second SMF to make point-to-point traffic flow as specified . The SMF and the second SMF can cooperate to determine a path for point-to-point traffic, including the bridge. In some modalities, the SMF is further configured to receive, from the PCF, an indication of a specific path for point-to-point traffic, the path including the bridge, and in which the specified way causes point-to-point traffic. -point cross the path. In some embodiments, the underlying features include one or more user plan functions. In some embodiments, the SMF is further configured to notify the PCF when directing the underlying resources to detect and manipulate data traffic in the specified manner. In some embodiments, SMF is further configured to notify an application function (AF) by directing the underlying resources to detect and manipulate data traffic in the specified manner, where AF is associated with an application server that is ignored by flow of point-to-point traffic due to crossing the bridge, and where control messages associated with the flow of point-to-point traffic are routed to the application server.
[0038] [0038] In accordance with embodiments of the present invention, a method is provided for operating an SMF in the manner described above.
[0039] [0039] In accordance with the modalities of the present invention, a user plan function (UPF) is provided
[0040] [0040] In some of these modalities, the UPF is configured to receive instructions for configuring an application function (AF), the configuration instructions specifying characteristics of the point-to-point traffic flow and causing the UPF to monitor the flow point-to-point traffic based on the specified characteristics. In some modalities, at least one of the SMFs or the PCF is configured to notify the AF of the referred configuration or reconfiguration, the AF is associated with an application server that is ignored by the point-to-point traffic flow due to the bridge crossing , and control messages associated with the point-to-point traffic flow are routed to the application server.
[0041] [0041] In accordance with the modalities of the present invention, a method is provided for operating a UPF in the manner described above.
[0042] [0042] The modalities of the present invention refer to the configuration and operation of the SMF. In addition, some of these modalities are related to the relocation of the SMF, in which the service SMF position for a PDU session is reallocated from a source SMF to a target SMF. The modalities of the present invention relate to the configuration and operation of the PCF. In addition, some of these modalities refer to the relocation of the PCF, in which the PCF service post for a PDU session is reallocated from a source PCF to a target PCF. Prior to relocation, the source SMF (or PCF) is the service SMF (or PCF) for the PDU Session; after relocation, the target SMF (or PCF) is the service SMF (or PCF) of the PDU Session.
[0043] [0043] According to the modalities of the present invention, a policy control function (PCF) associated with a main network is provided. PCF uses a processor operationally coupled to memory and a network interface. The PCF is configured, in response to a request from an application function (AF) or other entity, to communicate with one or more session management functions (SMFs) to configure its traffic handling policies. The request refers to at least a first PDU session and a second PDU session, the first and second PDU sessions handling a common point-to-point (P2P) traffic flow, the first PDU session corresponding to the PDU traffic in a first portion of the core and a first portion of the radio access network, the second PDU session corresponding to the PDU traffic in a second portion of the core and a second portion of the radio access network. After such configuration, traffic manipulation policies configure the underlying resources to make the common point-to-point traffic flow cross a bridge, the bridge comprising one or more application functions or application servers that support the flow P2P traffic.
[0044] [0044] In some of these modalities, the PCF is further configured to jointly optimize a traffic flow path for the first PDU session, the second PDU session and the locations of said one or more application functions or application servers . In some embodiments, the configuration of the traffic handling policies comprises: directing a first underlying resource to configure the traffic handling policies for the first PDU session; direct a second underlying resource to configure traffic handling policies for the second PDU session; monitoring to confirm the first underlying resource and the second underlying resource that traffic handling policies have been configured in; and direct traffic manipulation policies to the first PDU session and the second PDU session to be implemented simultaneously after receipt of said confirmation.
[0045] [0045] In accordance with the modalities of the present invention, an application function configured to send a message indicating whether the user plan (UP) paths of two or more PDU sessions should be selected or reselected in set. In some of these modalities, selection or re-selection of one or both: a user plan function (UPF); and a selected or re-selected application location is performed based on joint selection or re-selection, and in which at least one of the aforementioned UPF and application location is shared by the UP paths. In some embodiments, the application function is configured to convey an indication of whether or not the UP paths of the two or more sessions should be connected via an application location. In some embodiments, the application function is configured to transmit a request by loading one or both: the aforementioned message indicating whether the user plan (UP) paths of two or more PDU sessions should be selected or re-selected together ; and indication of whether or not the UP paths of the two or more sessions should be connected via an application location. In some embodiments, the request further comprises information indicating a primary PDU session of the two or more PDU sessions or a primary UE of the two or more even-numbered PDU sessions.
[0046] [0046] In accordance with the modalities of the present invention, a policy control function (PCF) configured is provided to: receive a message indicating whether the user plan (UP) paths of two or more PDU sessions should be selected or re-selected together; and transmitting an instruction to a session management (SMF) function indicating that the user plan (UP) paths of two or more PDU sessions should be selected or re-selected together. In some of these modalities, the PCF is further configured to receive an indication as to whether or not the UP paths of the two or more sessions should be connected via an application location. In some modalities, the PCF is further configured to receive a request carrying one or both of: the aforementioned message indicating whether the user plan (UP) paths of two or more PDU sessions should be selected or re-selected together ; and indication of whether or not the UP paths of the two or more sessions should be connected via an application location.
[0047] [0047] In accordance with the modalities of the present invention, a session management function (SMF) is provided configured to: receive an instruction from a policy control function (PCF), the instruction indicating that the user plan paths (UP) of two or more designated PDU sessions must be selected together or re-selected; and to select or reselect the UP paths of the two or more designated PDU sessions, based on the instructions.
[0048] [0048] In accordance with the modalities of the present invention, a policy control function (PCF) is configured, configured to: receive, from an application function (AF), a message indicating that the user plan paths (UP ) of two or more PDU sessions must be selected together or re-selected; and select or re-select one or both: user plan functions (UPFs); and application locations, for use in connecting said UP paths from said two or more PDU sessions. In some of these modalities, the PCF is also configured to perform the said selection or re-selection in response to a trigger. In some modalities, the trigger is received from a session management function (SMF) or an access and mobility management function (AMF). In some modalities, the PCF is further configured to receive an indication that the UP paths of the two or more PDU sessions must be connected via an application location. In some embodiments, the PCF is further configured, after such selection or re-selection, to notify a session management function (SMF) of the selected or re-selected UPFs or application locations. In some modalities, the PCF is further configured to receive a message from a session management function (SMF) indicating that a connection related to one of the UP paths is ready, and confirming with SMF that the connection is established when connections related to all two or more PDU sessions are ready.
[0049] [0049] In accordance with the modalities of the present invention, a session management function is provided
[0050] [0050] Modalities of the present invention provide methods of operating PCF, AF, UPF, SMF or a combination thereof, according to the description above. BRIEF DESCRIPTION OF THE FIGURES
[0051] [0051] Other features and advantages of the present invention will become apparent from the following detailed description, taken in combination with the accompanying drawings, in which: FIG. 1 illustrates the initial P2P traffic flow before the bridge, according to an embodiment of the present invention; FIG. 2 illustrates the flow of P2P traffic after the bridge, according to an embodiment of the present invention; FIG. 3 illustrates different bridge configurations for the flow of P2P traffic, according to various embodiments of the present invention; FIG. 4 illustrates a high-level call flow involving operation of main network functions during the implementation of modalities of the present invention; FIG. 5 illustrates a P2P path establishment procedure provided in accordance with embodiments of the present invention; FIG. 6 illustrates a call flow carried out in accordance with a modality of the present invention, in which the PDU sessions involved are established before receiving the AF request; FIG. 7 illustrates a call flow performed according to another embodiment of the present invention, in which the PDU sessions involved are established before or after the AF request; FIG. 8 illustrates a flow of calls carried out in accordance with another embodiment of the present invention, in which one of the PDU sessions involved is established after receipt of the AF request; FIG. 9 illustrates a call flow procedure related to the establishment of a group session, according to an embodiment of the present invention; FIG. 10 illustrates a call flow involving a pair of AFs and an optimization of P2P UP, according to an embodiment of the present invention; FIGS. 11A and 11B illustrate indirect and direct P2P paths, respectively, according to other embodiments of the present invention; FIGS. 12A and 12B illustrate a call flow to implement joint UP path optimization involving multiple cooperating master and slave SMFs.
[0052] [0052] It should be noted that, throughout the accompanying drawings, similar characteristics are identified by similar reference numbers. DETAILED DESCRIPTION
[0053] [0053] The modalities of the present invention provide a method and an apparatus for the application function influenced by the traffic routing for point-to-point (P2P) communications on such a network. P2P traffic can be routed across a bridge between a user plan or associated RAN of a first pair and a user plan or associated RAN of a second pair, thus shortening the path of P2P traffic in relation to a standard case, such as where P2P traffic is routed through a common application server, or where an IP or Ethernet PDU is routed locally by an anchor UPF toward an anchor UPF of a target pair's PDU session. In some modalities, two or more anchor UPFs can be replaced by a single anchor UPF acting for multiple sessions. The method and the apparatus may involve operating one or a plurality of communication network functions, such as functions on the main network of a 5G network. These functions may include, for example, one or more policy control functions (PCFs), one or more session management functions (SMFs) associated with one or more PDU sessions, and one or more user plan functions ( UPFs) associated with the PDU sessions. The application functions (AFs) associated with the application server (AS) may also be involved, as well as other functions such as, but not necessarily limited to, a network exposure function (NEF), a unified data management function ( UDM) and unified data repository (UDR) function.
[0054] [0054] The modalities of the present invention are described with respect to the following scenario. However, it must be appreciated that the invention may be applicable to other scenarios. In the basic illustrative scenario, there are two PDU sessions in progress, that is, the PDU 1 session and the PDU 2 session. The PDU 1 session is established through the first user plan labeled UP-1. The PDU 1 session can be established to facilitate access to a data network (DN) through UP-1 by a first UE, labeled UE-1. The PDU 2 session is established through a second user plan labeled UP-2. The PDU 2 session can be established to facilitate access to the data network (DN) via UP-2 by a second UE, labeled UE-2. Conventionally, P2P application traffic between UE-1 and UE-2 is routed between the two PDU sessions by an application server (AS) resident in the DN. As another example, P2P application traffic can be routed between anchor UPFs from two UPs (or through a shared anchor UPF common to both UPs) based on location routing intelligence, in the case of IP or Ethernet traffic. According to some modalities, P2P application traffic can initially be routed through the AS in this manner before establishing a bridge, and P2P application traffic can bypass the AS after establishing the bridge. In other modalities, the bridge can be formed before the flow of P2P application traffic.
[0055] [0055] Without loss of generality, the UP-1 can, in some cases, be referred to as the source UP, while the UP-2, in some cases, can be referred to as the target UP. This can be illustrative in a scenario in which the UE-1 transmits data in the uplink direction and the UE-2 receives data in the downlink direction. However, it should be noted that P2P traffic can be bidirectional and different UPs can more generally be considered as correlated even UPs.
[0056] [0056] In various modalities, an indication is provided, for example, in a message, for example, request for PA, sent to an entity in the main network (5GC) (for example, a PCF entity) of an AF, of that two or more PDU sessions must be correlated. PDU sessions can be identified in the message (for example, AF request), for example, using session identifiers, identifiers (for example, GPSI or IP address) of the associated UEs, an identifier of a group of UEs, descriptions ( for example, tuple IP 5 (source address, source port, target address, target port, QoS marker), or a traffic filter identifier for traffic detection, application identifier, traffic identifier associated with the PDU session, or other relevant information (such as DNN, S-NSSAI). The indication can further indicate the purpose of the correlation, for example, to support non-multicast between the correlated PDU sessions or to support the multicast between the correlated PDU session. the paths to the correlated PDU sessions can be optimized together, along with the location of one or multiple intermediate application servers (or applications), if appropriate. along with the bridge, where the bridge may or may not involve one or more application servers (or application locations). In some modalities, the correlation can be performed in support of selective diffusion or non-selective diffusion, in relation to the correlation objective indicated by the AF. That is, when a group of UEs is established which requires a member to be able to multicast or non-multicast to other members, then the PDU sessions for the group of UEs can be correlated.
[0057] [0057] In various modalities, indicative PDU Session correlation information (known as PDU session correlation information) is provided, for example in a message, for example, AF request, sent to an entity on the main network ( 5GC) (for example, a PCF entity) of an AF, indicating that two or more PDU sessions must be correlated or are already correlated. This information can be or include an indication as described above. The indication can be in the form of a single bit (for example, 0 indicating that sessions are correlated or uncorrelated; 1 means the opposite of the meaning of 0) or a sequence of bits (for example, a specific combination of bits indicating that sessions are correlated or uncorrelated).
[0058] [0058] In several modalities, this information may include or be associated with the requirement information (s) in the (re) selection path for PDU sessions identified or indicated as correlated in the message. Requirements information about the UP path (re) selection for correlated PDU sessions can indicate how the UP path of the PDU sessions should or is expected to connect to each other as a result of the UP path (re) selection , for example, through a common UPF (that is, the same UPF is included / shared in the UP paths of correlated PDU sessions) or through a common application location (i.e., the sessions UP paths correlated PDUs connect to the same application location). The information of the requirement (s) in the UP path (re) selection for correlated PDU sessions is indicated or included in the message sent to the entity in the main network from the AF. The information can be, for example, equivalent to or in the form of the bridge requirements information described below, or equivalent to the type of bridge to be used (for example, UPF based bridge, application location based bridge) described elsewhere place in this document.
[0059] [0059] In several modalities, the information of the requirement (s) in the UP path selection (s) for correlated PDU sessions can be provided or indicated implicitly, for example, in the form of a correlation objective combination (for example, indicating to support what type of traffic, such as multicast traffic or broadcast traffic, between correlated PDU sessions) and potential application locations (for example, in the form of DNAIs). For example, if the purpose of the correlation indicates support for multicast / broadcast traffic and potential application locations are missing or not provided, the UP paths of the correlated PDU sessions can be considered to be or are expected to be connect via a common UPF. If the purpose of the correlation indicates support for multicast / broadcast traffic and potential application locations are present or provided, the UP paths of the correlated PDU sessions can be considered to be or are expected to connect through a common application location selected among potential application locations.
[0060] [0060] In several modalities, the message, for example, AF request, sent to an entity in the main network (5GC) (for example, PCF) of an AF indicates information of bridge requirements for the purpose of directing P2P traffic or UP P2P path optimization between correlated PDU sessions (for example, a source PDU Session and a target PDU Session). A bridge between two PDU sessions connects the UPs of the two PDU sessions. The bridging requirement information can indicate whether the bridges between the correlated PDU sessions need to pass through the locations of one or more application servers or associated applications. When bridges do not need to pass through these locations, bridges connect the UP paths of the PDU sessions directly, through a common UPF or links between the UPFs. When the bridge passes the application server, the bridge requirements may include information indicative of an interconnection between application servers (or application locations), such as cost and connectivity quality information (for example, delay, throughput) and weight information for each application server (or application location).
[0061] [0061] FIG. 1 illustrates the initial flow of P2P application traffic before the bridge, according to an example of the embodiment of the present invention. Both control messages 130 and data messages 135 between UE-1 102 and UE-2 104 pass through the AS 120 (or alternatively through the link between the anchor UPFs or the shared anchor UPF of the two UPs). UPF-1 110 and UPF2 112 denote one or more functions of UP-1 and UP-2, respectively. UE-1 and UE-2 access the network via wireless communication, using the illustrated RAN entities 106, 108.
[0062] [0062] FIG. 2 illustrates the flow of P2P application traffic after the bridge, according to an example of a related embodiment of the present invention. Control messages 130 between UE-1 102 and UE-2 104 continue to pass through AS 120 (in the present example). However, data messages 135 between UE-1 102 and UE-2 104 now cross a bridge between UPF-1 110 and UPF-2 112. Thus, data messages are manipulated via a shortcut between the two UPs , for example, within the main network user plan (for example, 5GC). It is also noted that, in some embodiments, UPF-1 110 and UPF-2 112 can be merged into a common entity in both FIG. 1 and FIG. 2. Other configurations for the bridge, such as between the two RAN 106, 108 entities or between a RAN and UPF-1 110 or UPF-2 112 entities, can also be implemented.
[0063] [0063] FIG. 3 illustrates different bridge configurations according to various embodiments of the present invention. UP-1 320 includes at least one anchor UPF, referred to as UPF-1 322, and another UPF, referred to as UPF-3 324. UP-2 330 includes at least one anchor UPF, referred to as UPF-2 332, and another UPF, referred to as UPF-4 334. An anchor UPF can be a PDU session anchor from the PDU session user plan. UPF-3 324 and UPF-4 334 can be inserted into their host UPs as a result of the influence of FA. For example, UPF-3 324 and UPF-4 334 can be instantiated as part of the UP configuration operations according to the modalities of the present invention. In other embodiments, one or both of UPF-3 324 and UPF-4 334 can be omitted. In addition, additional UPFs (not shown) can be included in one or both of the UP-1 320 and UP-2 330.
[0064] [0064] Different embodiments of the present invention may use different bridges than the illustrated bridge configurations. Some modes can use multiple bridges from the illustrated bridge configurations, both simultaneously and sequentially. Each bridge corresponds to a unidirectional or bidirectional communication link between the UP-1 or a RAN associated with it and the UP-2 or an RAN associated with it.
[0065] [0065] Now having reference to FIG. 3, a first bridge (301) is located between UPF-1 322 and UPF-2 332. Using this bridge, traffic (i.e., selected P2P traffic) is routed between the anchor UPFs of the two PDU sessions. This can be enabled by TNL for IP or Ethernet PDUs, for example. For unstructured PDUs, this is enabled by the present application. A second bridge (302) is located between UPF-1 322 and UPF-4 334. Using this bridge, traffic is directed from UPF-1 322 to UPF-4
[0066] [0066] A fifth bridge (305) is located between UPF-2 332 and RAN 326 associated with UP-1 320. Using this bridge, traffic is directed from a node of this RAN 326 to UPF-2 332. This may correspond to a scenario in which the UPF-2 332 is re-selected as the anchor UPF of the PDU session for the UP-1 320 (for example, source session). A sixth bridge (306) is located between UPF-3 324 and UPF-4
[0067] [0067] Alternatively to a bridge formed as a data link, a common UPF (310) (also referred to as a UPF bridge) can be used to form the bridge. The common UPF (310) is shared between the UP-1 320 and the UP-2 330. The common UPF receives P2P uplink traffic in UP-1 and forwards P2P traffic in the downlink direction to UP-2 . Although the common UPF (310) is shown separately, it can be provided as a combination of UPF-3 324 and UPF-4 334, or possibly as a combined replacement for UPF-1 anchor 322 and UPF-2 anchor 332. Note- It is known that the third (303) and the fifth (305) bridges also employ a common UPF due to the re-selection of the anchor UPF.
[0068] [0068] The bridges illustrated in FIG. 3 can be traversed by the flow of point-to-point traffic, and can generally be described as bridges between a first portion of the core or the first portion of the radio access network and a second portion of the core or the second portion of the radio network. radio access.
[0069] [0069] For the first to sixth bridges 301, 302, 303, 304, 305, 306 illustrated in FIG. 3, N6 or N9 can be created. For the third and fifth UPF-to-RAN 303, 305 bridges, as well as the common UPF 310 case, the bridge can be created in the involved UPF, that is, UPF-1 322 or UPF-2 324.
[0070] [0070] In several modalities, the PDU 1 session is managed by a first session management function, referred to as SMF-1, and the PDU 2 session is managed by a second session management function, referred to as SMF- two. In some modalities, SMF-1 and SMF-2 are separate entities. In other modalities, SMF-1 and SMF-2 are integrated together or provided as a single entity. For example, the same SMF can be selected over the network to serve both PDU sessions. Although the two SMFs are illustrated separately for clarity, it should be understood that, when integrated together, the interaction and message passing between the two SMFs, as defined in various modalities below, can occur in a different internal way or can be omitted entirely when it is unnecessary.
[0071] [0071] In various modalities, AF indicates session information for at least two even sessions (for example, source and target PDU session) for elements of the main network (for example, 5GC). This is applicable to the scenario where P2P traffic must be detected and routed between at least two even sessions over a bridge, as described above. One or both PDU sessions can be an ongoing (pre-existing) session or a future (for example, anticipated) PDU session. One or both of the PDU sessions can be a single EU PDU session or a multi-EU (group) PDU session. As such, the modalities of the present invention are applicable to P2P broadcast traffic (unicast), multicast or broadcast, for example, defined based on the EU grouping or the geographical area. Note that more than two PDU sessions can be involved in P2P communication and indicated by the AF and that modalities of the present invention can be applied to more than two PDU sessions in a paired way.
[0072] [0072] In addition, the AF can provide traffic filtering information (for example, filter parameters) indicative of a desired portion of UL traffic, such as the UL traffic associated with the source PDU session.
[0073] [0073] Based on the information provided by the AF, the elements of the main network are configured to correlate multiple (for example, two) PDU sessions, so that a specified portion of the uplink traffic of one of the PDU sessions is routed over a bridge (for example, directly, bypassing the AS), to the UP of another PDU session, where it is treated as downlink traffic. The specified portion of traffic can be defined and detected using a properly implemented traffic filter configured based on traffic filtering information.
[0074] [0074] In some modalities, the PCF takes the correlation decision and generates a session correlation policy. In some embodiments, SMFs from one or more of the PDU sessions (for example, the source SMF, the target SMF or a combination thereof) obtain the session correlation policy. SMFs can obtain the session correlation policy, for example, by transmitting a request to the PCF during session establishment or after receiving and processing a policy update notification.
[0075] [0075] In some modalities, when the configured elements of the main network detect the traffic of the source PDU session with correspondence to the traffic filter parameters specified by the AF, these elements can trigger the establishment of the target PDU session, if the Target PDU does not exist. In example implementations that allow this, the UPF of the source PDU session in FIG. 2 detects traffic matching filter parameters and notifies the source SMF after this detection. In some modalities, the source SMF notifies the AF, which triggers the establishment of the target PDU session. In some modalities, the source SMF notifies the PCF, which triggers the establishment of the target PDU session. In some modalities, the source SMF triggers the establishment of the target PDU session directly. During the establishment of the target PDU session, the PCF can apply the source SMF to be selected for the PDU session.
[0076] [0076] The modalities of the present invention involve determining a desired efficient path for P2P traffic. The determination may comprise the selection of one of the bridges illustrated in FIG. 3, for example. The bridging entity is used to direct P2P traffic from a UPF selected in the UP of the source PDU session (or associated RAN node) to a UPF selected in the UP of the target PDU session (or associated RAN node). The determination and implementation of the path may include, additionally or alternatively, the configuration and addition of one or more UPFs to the UPs of one or both of the source and target PDU sessions. Determining and implementing the path may additionally or alternatively include selecting a UPF for the UPF from one or both sessions of the source and target PDU.
[0077] [0077] The determination of the desired efficient path for P2P traffic can be performed by one or a combination of entities in the main network, for example, as described below. This operation corresponds to the step of "determining the P2P path", as illustrated in several figures disclosed in this document.
[0078] [0078] In some modalities, the PCF determines the P2P path. The PCF can interact with the SMFs involved to obtain the UP path structure, which can be used in the path determination decision. The SMFs involved manage the PDU sessions even for the P2P path. The interaction with the SMF can be direct or through a third network function, such as a storage function in which the SMFs store updated UP path information. The storage function can be a UDSF (Unstructured Data Storage Function), UDM (Unified Data Management Function), or UDR (Unified Data Repository), for example. The PCF can then provide relevant decision information to the SMFs involved, such as those that manage the source and target PDU sessions. This information can include the complete determined P2P path or relevant parts of it (for example, the parts related to the respective UPs of the PDU sessions managed by the SMFs), or configuration instructions to implement the determined P2P path. The SMFs involved adequately configure or reconfigure the UPs of the PDU sessions managed in this way. In that case, the SMF-based P2P path procedure (as illustrated for example in FIG. 5) can be omitted. Note that this approach, with the PCF determining the P2P path, can be applied to various scenarios such as the three scenarios described elsewhere in this document.
[0079] [0079] In some modalities, the policy contains information indicative of the PDU sessions involved (for example, source and target) and the SMF is configured to determine the UP path (for example, direct) between the PDU sessions involved. The determination by the SMF can be based on at least the policy information received.
[0080] [0080] In some modalities, multiple SMFs involved (for example, source SMF and target SMF) interact through messages to negotiate the path. The negotiated path implementation may comprise adding, removing, or adding and removing, one or more UPFs. UPFs added or removed can belong to the source UP path, target UP path, or both. Addition and removal can be performed as part of implementing an efficient direct path, including a bridge portion of the path. The interaction can be initiated by one of the SMFs involved, such as the source or target SMF. The interaction may involve exchanges, sharing, or exposure, between the SMFs involved, of the UP path structures of the PDU sessions involved. The interaction can be direct or mediated by a third network function, such as a storage function in which SMFs store updated UP path information. The storage function can be a UDSF, UDM or UDR, for example. In some modalities, each of the SMFs involved can independently make the same UP path decision. In some modalities, one of the SMFs involved takes the UP path decision and informs another SMF involved in that decision. In some modalities, each of the SMFs involved makes UP path decisions in relation to their own PDU session, and exchanges information (for example, any address, port number, an ID) about only the UPF that must connect to the UP from another PDU session.
[0081] [0081] In some modalities, the PCF can provide policy information to one of the SMFs, thus triggering the SMF to deliver the PDU session corresponding to the other SMF.
[0082] [0082] Note that the UP configuration or reconfiguration of the PDU sessions involved is performed by one or more SMFs associated with these PDU sessions. This configuration can include part or all of adding UPF, removing UPF, reselecting UPF, and configuring or reconfiguring traffic routing.
[0083] [0083] FIG. 4 illustrates a high-level call flow involving operation of main network functions during the implementation of modalities of the present invention. As in FIG. 3, an application server (AS) 420 is connected to both a first UP (UP-1) 436 and a second UP (UP-2) 456. A first UE (EU-1) 432 and a second UE (EU- 2) 452 are coupled to UP-1 436 and UP-2 456, respectively, through associated RAN infrastructures 434, 454. As an example, UE-1 432 can be considered a source of P2P traffic and UE -2 452 can be considered a destination for P2P traffic, although it is noted that such traffic can be bidirectional. An application function (AF) 422 is associated with AS 420 and can be integrated with AS. That is, AF 422 and AS 420 can be the same entity. A network exposure function (NEF) 424 is provided as an intermediary between AF 422 and main network functions, such as PCF 440, 460 functions. In some embodiments, NEF 424 can be integrated with AF 422, in which case messages (401) and (402) are internal AF messages.
[0084] [0084] FIG. 4 illustrates two PCFs in communication with the NEF. PCF-1 440 is associated with a first PDU session involving UE-1 432 and UP-1, and PCF-2 460 is associated with a second PDU session involving UE-2 452 and UP-2. In some embodiments, PCF-1 440 and PCF-2 460 can be integrated and delivered as the same entity. FIG. 4 also illustrates two SMFs. SMF-1 438 is associated with the first PDU session and PCF-2 458 is associated with the second PDU session. In some embodiments, SMF-1 438 and SMF-2 458 can be integrated and delivered as the same entity, in which case message (407) becomes an internal SMF message. It is also noted that, in some modalities, the UP-1 and UP-2 may overlap partially or totally, as some or all UPFs can be shared by both UP-1 and UP-2.
[0085] [0085] The call flow of FIG. 4 can be considered as comprising two comprehensive steps. First, the influence of AF 422 for the P2P messaging system is installed or established in order to correlate a source PDU session with a target PDU session. This first step involves messages (401), (402), (403a), (403b), (404a) and (404b). Second, the influence of AF is applied. The application can be considered to occur when SMF (s) 438, 458 obtains relevant policy information, for example, during session setup or after receiving notification from a PCF 440, 460. This second step involves messages ( 405a), (405b), (406a), (406b), (407), (408a), (408b), (409a) and (409b). The call flow generally causes the AF request to be relayed to PCFs 440, 460, which in turn trigger the operation of SMFs 438, 458, directly or indirectly, triggering policy update operations and configuration operations for P2P path in support of P2P path manipulation and efficient path routing, as described here. Some information mapping can be performed by NEF 424. PCFs 440, 460 generate policies based on the AF request and provide policies for SMFs 438, 458. SMFs, according to policies, perform P2P traffic handling , including establishing a P2P path and configuring traffic routing at the end points of the bridge entity.
[0086] [0086] In more detail, message (401) is an AF request made by AF 422; message (402) is an AF request response or retransmitted by NEF 424; messages (403a) and (403b) are translated or untranslated AF requests, transmitted by NEF to the two PCFs 440, 460; and messages (404a) and (404b) are responses to translated or untranslated AF requests from the two PCFs 440, 460 to NEF 424. Messages (405a) and (405b) are policy update messages from two PCFs 440 , 460 for their respective SMFs 438, 458. Messages (406a) and (406b) are responses to policy update messages. The message (407) corresponds to the negotiation or other communication between SMFs 438, 458, of the UP configuration or reconfiguration parameters and can include several messages in one or both directions. Messages (408a) and (408b) are UP path configuration or reconfiguration messages sent from SMFs 438, 458 to their corresponding UP 436, 456 or UPFs. Messages (409a) and (409b) are responses to the UP path configuration or reconfiguration messages sent from UPs 436,
[0087] [0087] In various modalities, the corresponding messages and responses of FIG. 4 occur in pairs, so that a message triggers its corresponding response. However, it is also contemplated that responses can be end to end. For example, the receipt of a UP (409a) or (409b) path (re) configuration response can trigger the receiving SMF 438, 458 to transmit a notification to the corresponding PCF 440, 460, which in turn transmits a notification to NEF 424, which in turn transmits a notification to AF 422. Likewise, responses can be partially forwarded through the function chain, rather than end to end. It should be noted that several acknowledgment or response messages, such as those described in relation to FIGs. 4 to 9, can be provided in some, but not necessarily in all modalities. Some or all of these response or acknowledgment messages can be omitted, or delivered through the transport layer.
[0088] [0088] FIG. 5 illustrates a P2P path establishment procedure provided in accordance with embodiments of the present invention. This procedure can be included, where indicated, within the procedures of FIGs. 6 to 8, as well as more generally. In such cases, M-SMF can correspond to one of SMF-1 and SMF-2, and S-SMF can correspond to another of SMF-1 and SMF-2. Here and elsewhere, operations called dashed boxes or arrows can be omitted in some ways, or they can represent one of several alternatives.
[0089] [0089] In some embodiments, two SMFs involved are referred to as a SMF master (M-SMF) and a slave SMF (S-SMF). M-SMF executes the P2P path decision between the PDU 1 session (whose UP is indicated by UP-1) managed by S-SMF and the PDU 2 session (whose UP is indicated by UP-2) managed by M - SMF. The P2P path decision is provided to S-SMF by M-SMF.
[0090] [0090] The designation of which SMF involved is M-SMF and which is S-SMF can be specified, for example, by the operator policy. S-SMF and M-SMF can obtain information on operator policy through an independent procedure. It should be noted that, in other modalities, the SMFs involved do not necessarily operate in a master-slave arrangement with one another, or the master-slave arrangement can be changed in several ways.
[0091] [0091] Continuing with the above mode, M-SMF (re) configures UP-2 for the P2P path. If enabled or allowed, M-SMF can also (re) configure the UP-1 for the P2P path. If the M-SMF is not able or allowed or determines (for example, according to the operator policy or the location configuration) not to (re) configure the UP-1, the (re) configuration of the UP-1 is performed by S-SMF. This (re) configuration can occur after the S-SMF receives P2P path decision information from the M-SMF. According to the operator policy or the location configuration, the S-SMF, M-SMF or both can notify the PCF after completing the P2P path establishment procedure.
[0092] [0092] Now having reference to FIG. 5, the P2P path establishment proceeds as follows. In operation (501), M-SMF 524 determines the need for a P2P path according to an operator policy and notifies S-SMF 522 that P2P path establishment is necessary. This step is optional. In operation (502), S-SMF 522 detects the need for the P2P path (operator policy or notification in operation (501)) and sends a request to M-SMF 524 to start establishing the P2P path. At that point, the S-SMF 522 can provide information about the PDU 1 session to the M-SMF 524, if the information is available. That information may include, for example, one or more of the following: UE IP address / prefix; a session ID; UP-1 composition and structure information; and N6 tunnel information related to the main network. In operation (503), M-SMF 524 obtains, from PCF 528, the operator policy if it does not have a valid operator policy. The operator policy may include rules that regulate the establishment / manipulation of P2P path traffic.
[0093] [0093] In operation (504), a P2P path determination is made according to the operator policy and the information of the two PDU sessions. In the modality currently illustrated, the M-SMF 524 determines the P2P path of the two PDU sessions. The P2P path covers the UP-1 530 (fully or partially) and the UP-2 532 (fully or partially) and includes a bridge entity (for example, bridge link or bridge UPF) between the two associated UPs or RANs to him. In other modalities, as already described above, the P2P path determination can be done by PCF 528, or by one or a combination of SMFs involved in the PDU sessions.
[0094] [0094] In operation (505), M-SMF 524 (re) configures the UP-2 532 to enable the P2P path. This includes configuring the traffic routing behavior of the end point of the bridge connection on the UP-2. This can also include adding, removing and relocating UPFs to the UP-2. In operation (506), the M-SMF 524 (re) configures the UP-1 530 to enable the P2P path. This includes (re) configuring the traffic routing behavior of the end point of the bridge connection on the UP-1. This can also include adding, removing and relocating UPFs to the UP-1. Operation (506) will not be performed if the M-SMF 524 is not allowed or enabled to (re) configure the UP-1 530. In this case, the S-SMF 522 can perform the (re) configuration of the UP-1. In operation (507), M-SMF 524 responds to S-SMF 522 in relation to the P2P operation path request (502). The response may indicate adding, removing and relocating UPFs on the UP-1 530 to the P2P path. The response may include information indicating the end point of the bridge connection on the UP-1 530 and information to (re) configure the traffic routing behavior of that end point. The response can instruct the S-SMF 522 to perform the (re) configuration of UP-
[0095] [0095] In operation (508), if the (re) configuration of the UP-1 530 has not yet started with the M-SMF 524, as indicated in operation (507), the S-SMF 522 (re) configures the UP- 1 530 to enable the P2P path. This includes configuring the traffic routing behavior of the end point of the bridge connection on the UP-1 530. This can also include adding, removing and relocating UPFs to the UP-1 530. In operation (509), S- SMF 522 notifies M-SMF 524 that the UP-1 has been (re) configured. Operation (509) can be omitted if operation (508) is omitted. In operation (510a) S-SMF 522 notifies PCF 528 that the P2P paths have been established. Additionally or alternatively, in operation (510b) M-SMF 524 notifies PCF 528 that P2P paths have been established. These operations can be omitted, for example, if the operator policy or the location setting does not indicate the need for such notification.
[0096] [0096] FIG. 6 illustrates an embodiment of the present invention in which the PDU sessions involved (PDU 1 session and PDU 2 session) are established before receiving the AF request. The AF request may result from the detection of AF point-to-point traffic. In this case, the AF request triggers the establishment of an immediate P2P path.
[0097] [0097] In the operation (601) of FIG. 6, AF 642 sends an AF request (that is, the request for directing P2P traffic) to PCF 634 if AF is allowed to interact directly with PCF (for example, when AF integrates NEF and / or when AF is deployed in the trust domain). Otherwise, the AF sends the AF request to NEF 640, which transfers it to PCF 634. Before the transfer, NEF can perform information mapping. Prior to operation (601), as illustrated, P2P traffic between UE-1 622 and UE-2 624 is routed through the DN. The detection of this traffic can trigger the operation AF request (601).
[0098] [0098] In operations (602a) and (602b), PCF 634 generates or updates PCC rules for the two PDU sessions. PCF 634 updates the PCC rules for SMF-1 628 (operation 602a) and SMF-2 630 (operation 602b). Operations (602a) and (602b) can include the following sub-operations. In a first sub-operation (602-1), PCF 634 notifies SMF 628,
[0099] [0099] In operation (603), a P2P path is established between the two PDU sessions. The path establishment is described above, for example, with reference to FIG. 5.
[00100] [00100] In operation (604), PCF 634 responds to AF, indicating that the handling of P2P traffic is in effect. As illustrated, after operation (604), P2P data between UE-1 622 and UE-2 624 are routed through UP-1 636 and UP-2 638, but are no longer routed through DN 644 (as shown in Figure 6 by way of an illustrative but not limiting example; in another example case, traffic may have been originally routed through PDU session anchors). In other modalities, the bridge can involve at least one RAN 626 node. Non-P2P data from UE-1 622 and UE-2 624,
[00101] [00101] In operation (605), after a subsequent activation, any of the SMF-1 628 and SMF-2 630 (or another entity) can start the procedure of establishing a P2P path to modify the P2P path. Possible triggers include UE mobility, UPF loading problems, transport layer congestion, user plan failure, etc.
[00102] [00102] Note that, for the embodiment illustrated in FIG. 6, the PDU 1 session and the PDU 2 session are established before the AF request. The AF request can be transmitted as a result of detecting AF point-to-point traffic. This mode allows AF to substantially trigger the establishment of an immediate P2P path.
[00103] [00103] FIG. 7 illustrates an embodiment of the present invention in which the PDU sessions involved (PDU 1 session and PDU 2 session) can be established before or after the AF request.
[00104] [00104] The embodiment of FIG. 7 is applicable to the scenario in which the AF did not detect P2P traffic, and the request indicates that the P2P path establishment should be started after the detection of the designated P2P traffic. In this case, SMF-1 and SMF-2 according to the policy (obtained during session establishment or upon policy update notification) configure the UP of your service PDU sessions (for example, the session anchor ) to detect P2P traffic (for example, a certain type, based on certain filter parameters). When P2P traffic is detected, UP triggers traffic manipulation
[00105] [00105] To detect P2P traffic in the UL direction, the SMF can configure a UPF closer to the RAN in the UP. To detect P2P traffic in the DL direction, SMF can configure a UPF closer to the DN in the UP.
[00106] [00106] P2P traffic detection can be performed, for example, by verifying whether the destination address (including address and possibly port number) or source address (including address and possibly port number) of a PDU is an address assigned by network (for example, within the cluster of IP addresses managed by the network). To verify that UL traffic matches P2P traffic, the destination address can be verified. To verify that DL traffic is P2P traffic, the source address can be verified. SMF can configure the UP to perform P2P traffic verification only on UL traffic or just DL traffic or both UL and DL traffic, depending on the policy. Some or all of the candidate PDUs can be verified in this way through traffic filtering or inspection of operations packages.
[00107] [00107] With reference now to FIG. 7, in operation (701), AF 742 sends the request to direct P2P traffic to PCF 734 if the AF is allowed to interact directly with the PCF. Otherwise, AF 742 sends the request to NEF 740, which transfers it to PCF
[00108] [00108] In operations (703a) and (703b), the two PDU sessions 1 and 2 are established. During PDU session establishment, SMFs 728, 730 can operate to identify the need for P2P traffic detection based on the operator policy and configure their associated / involved UPs to detect P2P traffic according to the policy and / or configuration location. P2P traffic checks can be configured for one or both of UL traffic and DL traffic. One or both of the SMF-1 728 and SMF-2 730 can perform the P2P traffic detection configuration. For example, only the SMF master, only the SMF slave, or both, the SMF master and slave, can perform the configuration.
[00109] [00109] In operations (704a) and (704b), the UP-1 738 and UP-2 740 detect P2P traffic and notify the associated SMF 728, 730. One or both operations (704a) and (704b) can occur, for example, depending on whether the P2P traffic check is performed against both UL traffic and DL traffic. At that point, the UPF can inform SMF about P2P traffic information, for example, information about the source address and destination address associated with P2P traffic, a reference number, such as an application identifier, which is mapped to the rule or P2P traffic detection configuration.
[00110] [00110] In operations (705a) and (705b), SMFs 728, 730 obtain policies related to P2P traffic. These operations can be omitted in some ways. These operations are similar to operations (602a) and (602b), as illustrated in FIG. 6
[00111] [00111] In operation (706), a P2P path between the two PDU sessions is established. The path establishment is described above, for example, with reference to FIG. 5.
[00112] [00112] In operations (707a) to (707c), which represent several alternatives, AF 742 is notified that the establishment of a P2P path / traffic manipulation is being or has been implemented. The notification can be sent (707a) by PCF 734 or (707b) by SMF-2 730 or (707c) by SMF-1. If the notification is sent by an SMF, which of the SMF-1 728 and SMF-2 730 sends the notification can be specified by the operator policy. As illustrated, after operation (706), P2P data between UE-1 722 and UE-2 724 are routed through UP-1 736 and UP-2 738, but are no longer routed through DN 744 (again as shown in illustrative title, but not a limiting example). In other modalities, the bridge can involve at least one RAN 726 node. Non-P2P data from UE-1 722 and UE-2 724, such as, but not limited to control messages, can still be routed to the DN
[00113] [00113] In operation (708), in a subsequent activation, both SMF-1 728 and SMF-2 730 (or another entity such as PCF 734, for example, as described elsewhere in this document) can initiate the procedure establishing a P2P path to modify the P2P path, similar to the operation (605) of FIG. 6
[00114] [00114] Note that, in the embodiment illustrated in FIG. 7, the PDU 1 session and the PDU 2 session can be established before or after the AF request. AF 742 may initially not have detected P2P traffic, and the request indicates that the P2P path is expected when P2P traffic occurs. This modality allows the AF to install the P2P traffic manipulation policy before P2P traffic occurs.
[00115] [00115] FIG. 8 illustrates a modality in which one of the PDU sessions involved (PDU 1 session) is established after the request for PA. The AF request indicates that the UP must be ready for P2P traffic substantially immediately. It is assumed here that the PDU 2 session was established before the PDU 1 session. Due to the initial lack of peer information (ie, initial lack of identity of the PDU 1 session), the PDU 2 session may have been established through another procedure (such as, but not necessarily limited to, the regular session setting procedure described in 3GPP TS
[00116] [00116] With reference now to FIG. 8, in operation (801) AF 842 sends the request to direct P2P traffic to PCF 834 if the AF is allowed to interact directly with the PCF. Otherwise, AF sends the request to NEF 840, which transfers it to PCF 834. Before the transfer, NEF can carry out information mapping. In operation (802) PCF 834 responds to AF 842 in relation to the request for directing P2P traffic, indicating acceptance of the request.
[00117] [00117] In operation (803), PDU 2 session is established for UE-2 824. In operation (804), UE-1 822 requests the establishment of PDU 1 session. The request can be transmitted to SMF- 1. In operation (805), SMF-1 828 obtains a relevant operator policy through interaction with PCF 834. In operation (806), SMF-1 828 requests RAN 826 (located between EU-1 and SMF- 1) that configure resources to support the PDU session 1. In operation (807), RAN 826 responds to SMF-1 828, indicating the completion of the configuration of RAN resources for the PDU 1 session.
[00118] [00118] In operation (808), a P2P path between the two PDU sessions is established. The path establishment is described above, for example, with reference to FIG. 5. The path establishment procedure can be initiated by the SMF-1 operating as an SMF master or SMF slave. In operation (809), SMF-1 828 responds to UE-1 822, indicating acceptance of the PDU 1 session.
[00119] [00119] In operations (810a) to (810c), which represent several alternatives, AF 842 is notified that the establishment of a P2P path / traffic treatment is being or has been implemented. The notification can be sent (810a) by PCF 834 or (810b) by SMF-2 820 or (810c) by SMF-1 828. If the notification is sent by an SMF, which of SMF-1 and SMF-2 sends the notification can be specified by the operator policy. As illustrated, following operation (808), P2P data between UE-1 822 and UE-2 824 is routed via UP-1 836 and UP-2 838, but is no longer routed via DN 844 (again as shown illustrative but not limiting example). In other modalities, the bridge can involve at least one RAN 826 node. Non-P2P data from UE-1 822 and UE-2 824, such as, but not limited to control messages, can still be routed to the DN
[00120] [00120] In operation (811), after a subsequent activation, SMF-1 828 and SMF-2 830 (or another entity) can initiate the procedure for establishing the P2P path to modify the P2P path, similarly to the operation (605) of FIG. 6
[00121] [00121] Note that, in the embodiment illustrated in FIG. 8, the PDU 1 session is established after the AF request. The AF request indicates that the UP must be ready for P2P traffic substantially immediately. It is assumed that the PDU 2 session was established before the PDU 1 session. This modality allows the manipulation of P2P traffic to be performed during the establishment of the PDU 1 session.
[00122] [00122] FIG. 9 illustrates a call flow procedure related to the establishment of a group session, according to an embodiment of the present invention. A single UE PDU session can be correlated with a group PDU session to enable P2P multicasting. In this multicast, the single UE multicast traffic to the UE group. The UP of the group PDU session can have a tree structure. One of the UPFs in the UP can be selected as the root of the tree by the SMF. The single UE sends UL traffic, which is routed through an established bridge to the UP tree of the group PDU session. The bridge can be established according to the modalities of the present invention. Within the UP tree, traffic is diffused along the tree. Each UPF in the tree, after receiving traffic, sends it to all topological neighbors in the UP (that is, the UPFs or RAN nodes that have a connection to it), except the UPF or RAN node from which it received the traffic. This can be facilitated by avoiding sending traffic to the tunnel end points that provided the traffic. RAN nodes receiving traffic can use multicast at the RAN level to optimize RAN performance if the RAN node is serving multiple members of the UE group.
[00123] [00123] To optimize the tree diffusion structure, each UPF can be configured with an indication of the number or presence of UEs served in each of the branches. The UPF then sends traffic to just that branch if that branch is serving one or more UEs. The configuration can be performed by the SMF of the group PDU session.
[00124] [00124] The SMF of the group PDU session can be specified as the SMF master. This can avoid the requirement to pass information from the complicated tree UP structure between SMFs. Each time a PDU session is added to the tree, the SMF updates information about the number or presence of UEs served in the UPFs along the branch of the tree towards the root of the UP tree, starting from the UPF connection, to facilitate tree diffusion optimization.
[00125] [00125] To maintain the UE count properly, each UE can be attached to the UP tree through only one PDU session. The single UE session SMF provides UE information for the group session SMF. The breakout SMF then enforces the applicable rules.
[00126] [00126] The call flow illustrated in FIG. 9 shows a modality of the group session establishment procedure. The procedure for establishing a P2P path for a single UE session and a group session is the same as for two single UE sessions.
[00127] [00127] Having now reference to FIG. 9, in operation (901) an AF request is sent for group session configuration. The order may indicate some or all: information from the EU group, the location area of the EU group, and the location of the application. In one embodiment, the order can designate all UEs within a specified location area and satisfy the other specified criteria. In operation (902), NEF 930 obtains the group's location information in UDM 924, if the information is not part of the AF request. Location area information can be based on location information for individual group members, for example, if individual information is available.
[00128] [00128] In operation (903), NEF 930 selects an SMF according to the UE group location information. In operation (904), NEF 930 asks SMF 922 to establish a group PDU session. The request indicates the application location. In operation (905) SMF 922 selects a PCF. In operation (906) SMF 922 obtains the operator policy for the selected PCF 926. In operation (907), SMF 922 selects an UPF according to the group location information and the application location information. Operation (907) can be omitted in some embodiments.
[00129] [00129] In operations (908a) SMF 922 configures the UP group session. The SMF can send a PDU session establishment request (908a) to initiate the configuration and receive the UP 928 PDU establishment response (908b) after accepting / completing the configuration. Operations (908a) and (908b) are optional and can be omitted in some modalities.
[00130] [00130] In operation (909) SMF 922 responds to NEF 930, indicating the successful establishment of the group session. The reply message can include the multicast address of the group session. In operation (910a), NEF 930 updates the subscription data in UDM 924, providing group session information to the UDM (including session information, such as the multicast address, group information, such as group ID or details group membership information, application information such as application ID). This step can be omitted in some modalities. In some modalities, instead of performing the operation (910a), the NEF 930 may instead provide, in the operation (910b), the same information described in the operation (910a) for PCF 926. In some modalities, both operations (910a) and (910b) can be performed. In operation (911), NEF 930 responds to AF 932 indicating acceptance of the group session. The response may include the multicast address of the group session.
[00131] [00131] In several modalities, the AF request indicates which portion of the UL traffic in a source PDU session should be directed to a target PDU session as DL traffic. The AF request includes some or all: PDU session information, such as source and target PDU session information, traffic filtering information, and traffic routing information.
[00132] [00132] The PDU session information (for example,
[00133] [00133] Traffic filtering information is used to identify traffic of interest, such as P2P traffic to be diverted. Traffic filtering information can include a flow decryptor, for example, involving a UE IP address, or a tuple IP 5. Traffic filtering information can additionally or alternatively include an application ID, traffic detection rules, or a combination of them. An example of a traffic detection rule indicates that only data flows should be affected by P2P traffic flow policy and handling, while control messages should not be affected and should instead be routed to AF , or the application, or the DN. In some embodiments, the traffic filtering information may include a reference to one or more pre-configured and known traffic detection rules. In some modalities, the traffic detection rules can be explicitly communicated.
[00134] [00134] Traffic routing information is used to enable the UPF to perform packet processing for routing purposes and for the purpose of handling P2P traffic. Traffic routing information includes information indicating how P2P traffic should be handled when detected. This includes information related to the routing of traffic across the bridge, for example, over a bridge entity (for example, bridging tunnel or UPF bridge). Traffic routing information can include a packet header processing configuration, protocol parameters, or both, or other information related to the bridge entity.
[00135] [00135] In addition, with regard to the modalities of the present invention, and signal content in particular, policy rules, such as operator policy and / or PCC rules, are provided to SMF by PCF. These policy rules can be used for the purpose of establishing P2P paths, handling P2P traffic, or both. Policy rules can be generated in response to one or more AF requests and can be configured or generated by PCF based on the content of those AF requests and used by SMF to optimize the UP path for handling P2P traffic. Policy rules may include or be indicative of some or all of the following information. The implementation of policy rules by an SMF may include the imposition of policy rules by the SMF.
[00136] [00136] In some modalities, the policy rules may be indicative of a decision information bridge. The bridge decision information can indicate UP path information, UP structure information, or both. This information can include, for example, any of a UPF ID, UPF interconnect information, functionality information for each UPF (for example, session anchor, UL CL, BP, etc.), or application location. The bridge decision information can include information about the identity of a partner PDU session, such as a PDU session ID or other PDU session information, as described above. The bridge decision information can include an indication of whether the partner SMF is the master SMF or the slave SMF, that is, whether the partner SMF is expected to make decisions like the P2P UP decisions. The bridge decision information can include bridge configuration information, such as a bridge source end and bridge destination end identifier. Bridge decision information can include traffic filtering information, traffic routing information, or both.
[00137] [00137] In some modalities, the policy rules may be indicative of the bridge requirements, for example associated with a bridge decision. The bridging requirement information can include information indicative of one or more partner SMFs, such as SMF IDs or addresses. The bridge requirement information can include information indicative of one or more partner PDU sessions, such as PDU session IDs, UP path information, or structural UP information. The bridge requirement information can indicate whether the bridge needs to pass application or application server locations. When the bridge does not need to pass application or application server locations, the bridge connects the UP paths of the PDU sessions directly, through a common UPF or link between UPFs. When the bridge passes the application server, the bridge requirements may include information indicative of interconnection between application servers (or application locations), such as cost information and connectivity quality (for example, delay, throughput) and information weight of each application server (or application location). The bridge requirement information in the policy rules can be derived by the PCF from the bridge requirement information provided by the AF in the AF requests. In some embodiments, the bridging requirement information in the policy rules is identical to the bridging requirement information provided by AF in AF requests. The bridge requirement information can include traffic filtering information, traffic routing information, or both.
[00138] [00138] In some embodiments, policy rules may indicate a requirement for PDU session transfer for handling P2P traffic, PDU session information, source SMF information (eg, address, ID), target SMF information (e.g., address, ID), traffic routing information, or a combination of them.
[00139] [00139] In some modalities, the policy rules may include indications of application location information. In some modalities, the application location information is expressed in the form of a data network access identifier (DNAI). In some embodiments, the application location information indicates whether a common application location should be selected for the first and second PDU sessions or for all two, three or more PDU sessions involved. In some embodiments, application location information includes interconnection information indicative of data connection parameters between multiple application locations. These parameters can include, for example: interconnection cost, connectivity, throughput, delay and weight that reflects any interconnection cost, connectivity, throughput and delay. In some embodiments, the application location information includes information indicating parameters of the application locations. These parameters can include, for example, cost, load, data / traffic processing capabilities (for example, data processing rate in terms of bits per second or packets per second or number of PDU sessions) and weight that reflects any cost, load, data / traffic processing capabilities.
[00140] [00140] In more detail, application location information can be provided in the event that two or more PDU sessions must be bridged through an application server, or through a plurality of application servers. In this case, the application locations and their associated servers are part of a connected application network, and the UEs are connected to the application network through one or multiple application servers. When an application server is involved, its application server acts as a bridge node, as described elsewhere in this document. When multiple application servers are involved, one or more bridge links are implemented in the application network between the multiple application servers. In some embodiments, when multiple application servers are involved, SMF is configured to base routing decisions at least in part on the interconnection information between multiple application servers. Note that an application server can refer to a portion of a larger server that handles multiple applications. In addition, the application location can be the location of an application server. For example, the application server can be a physical entity and the application location can be a logical construct that points to the application server location. As another example, the application location can be a DNAI, which provides access to the application server.
[00141] [00141] The AF may provide application location information, application location interconnect information, or both, as part of the AF request to entities (eg, PCF, SMF) in the network. This information can be provided, for example, when the AF transmits a request for handling P2P traffic and indicates that the P2P bridge must cross one or multiple application server (s). In response, entities (eg PCF and / or SMF) within the network will cause application locations (or associated servers or servers) to be present in the optimized P2P UP path together. This P2P UP path connects or bridges the two or more UPs of the PDU sessions. The selection or re-selection of the application location or application server can be performed according to the application location information and / or application location interconnect information provided by AF as part of an optimization routine to provide a path P2P UP great or close to great.
[00142] [00142] FIG. 10 illustrates a call flow involving a pair of AFs 1030, 1032 and an optimization of P2P UP, according to an embodiment of the present invention. Referring now to FIG. 10, in operation (1001), a first application function AF1 1030 requests correlation of AF influence from a second application function AF2 1032. The request indicates relevant information, such as application ID, DNN, S-NSSAI, UE information , and traffic information. AF2 1032 responds to AF1 1030 and includes information such as an AF transaction ID in the response. The AF transaction ID refers to the AF request that AF2 1032 sent (or will send) to the main network (for example, 5th generation main network (5GC)) and corresponds to the AF influence correlation requested by AF1 1030.
[00143] [00143] In operation (1002), AF1 1030 sends an AF request to the main network to influence the traffic routing decision made by SMF (s) SMF1 1022, SMF2 1024, or a combination thereof. Operation (1002) includes sub-operations (1002a) and (1002b). In suboperation (1002a), the AF request is sent to PCF 1026 directly or via NEF 1028. The AF request includes the AF transaction ID received from AF2 1032 in operation (1001), indicating that the AF request is correlated with the AF request identified by that AF transaction ID. In suboperation (1002b), PCF 1026 notifies SMF1 1022 (that is, SMF serving the traffic identified in the AF) of the policy update to the AF request in the suboperation (1002a).
[00144] [00144] If the correlated AF request has already been received by the PCF, the PCF in this step will include the even PDU session ID and the indicative service SMF information for the even PDU session. The PCF also indicates to the SMF (s) that the UP path must be optimized together for the two PDU sessions involved. The SMF therefore starts the optimization operations. If the correlated AF request has not been received by the PCF, the PCF at this time can include only the AF request information related to the current PDU session. That is, the AF request can be provided at the moment without any information about the correlation and the correlated PDU sessions.
[00145] [00145] In operation (1003), AF2 1032 sends an AF request to the main network to influence the traffic routing decision made by an SMF or a combination of SMFs. Operation (1003) includes sub-operations (1003a), (1003b) and (1003c). In sub-operation (1003a), the AF request is sent by AF2 1032 to PCF 1026, directly or via NEF 1028. The AF request includes the AF transaction ID that AF2 previously provided to AF1 in operation (1001). In sub-operation (1003b), PCF 1026 notifies SMF2 1024 of the policy update associated with the AF request provided in the sub-operation (1003a). SMF2 1024 is the SMF serving the traffic identified in the AF request. In suboperation (1003c), PCF 1026 notifies SMF1 1022 regarding the correlation in the AF influence, including the PDU session ID of the correlated PDU session and the service SMF of that PDU session. The sub-operation (1003c) can be omitted in some modalities, for example, if the sub-operation (1003b) occurs before the sub-operation (1002b).
[00146] [00146] In operation (1004), SMF1 1022 and SM2 1024 interact to optimize P2P UP. Subsequently, in operations (1005) and (1006), respectively, SMF1 1022 notifies AF1 1030 of the selected application location (due to optimization), and SMF2 1024 notifies AF2 1032 of the selected application location (due to optimization) . In operation (1007), AF1 1030 and AF2 1032 interact to configure the application-based PDU session bridge, as described elsewhere in this document (for example, bridge involving one or more application locations or application servers while along the bridge path.
[00147] [00147] In some modalities, only one of the AF1 1030 and AF2 1032 interacts with the main network to influence the routing of P2P traffic. For example, in operation (1001) of FIG. 10, AF2 can provide AF1 with application server information and correlated peer PDU session information. Then, in suboperation (1002a), the AF request sent from AF1 1030 includes information from both PDU sessions, along with the application server information from the two PDU sessions. After SMF1 1022 receives the PCC rules resulting from the AF request in the sub-operation (1002a), SMF1 1022 can trigger a P2P UP path optimization. In this case, the operation (1003) is optional and can be omitted in some modalities.
[00148] [00148] FIGS. 11A and 11B illustrate P2P paths according to different embodiments of the present invention. FIG. 11A illustrates an indirect P2P path through a data network, while FIG. 11B illustrates a direct P2P path within a 3GPP UP (and omitting the data network). P2P paths can support an IP multimedia subsystem (IMS) media session between UE1 1122 and UE2 1124. IMS is a defined and standardized architectural structure. In FIG. 11A, the P2P path includes two 3GPP UP path segments 1105, 1107 connecting the two UEs 1122, 1124 to the corresponding IMS media plan (and the same path). The path also includes a third segment 1109, which may be within the IMS media plan. The three segments 1105, 1107, 1109 of the P2P path can be optimized together to improve the efficiency of the P2P path. In some embodiments, application location 1 and application location 2 are the same application location.
[00149] [00149] In some embodiments, when a determination is made by network entities that an application server is not required on the P2P path, a direct P2P path (involving the direct connection of PDU session UPs) can be established as in FIG. 11B. When it is determined by network entities that an application server is needed as part of the P2P path, an indirect P2P path, involving that application server and the indirect connection of PDU session UPs, can be established as in FIG. 11A. The path optimization for the scenario of FIG. 11A can understand the selection of an application server location that supports optimization.
[00150] [00150] If the IMS media plan (and the path segments associated with it) can be omitted (for example, when the IMS signaling plan decides to do), the two 3GPP UP paths can be connected directly. This alternative is illustrated in FIG. 11B. The P2P path in this case includes a first path segment 1115 from RAN1 1126 to UPF1 1128, a second path segment 1117 from UPF1 1128 to UPF2 1130, and a third path segment 1119 from UPF2 1130 to RAN2 1132. In this case, the two 3GPP UP paths can be selected together to provide a desired level (for example, optimal or near optimal) of P2P path efficiency. In the modalities, UPF1 and UPF2 can be the same UPF.
[00151] [00151] Modalities of the present invention (including, but not necessarily limited to, the modalities illustrated in FIGS. 11A and 11B) enhance the influence of AF on traffic routing to provide a desirable P2P path (for example, optimized or nearly optimized). For example, this can improve the influence of AF described in the document of the Third Generation Partnership Project (3GPP), numbered TS 23.501 (hereinafter referred to as TS 23.501), “System and Architecture for the 5G System”, version 15.0.0, December 22, 2017 and, in particular, in clause 5.6.7. This document is incorporated here by reference. These modalities allow AF to indicate a correlation between two AF requests to entities (for example, PCF, SMF) on the main network. In response, these main network entities can be configured to apply the AF influence defined in the two AF requests together with the relevant PDU Sessions for P2P path optimization. THE
[00152] [00152] In a first scenario, the AF may request to correlate two existing AF requests for path optimization between UEs. In this case, the AF can provide the AF transaction IDs of the two existing AF requests. One of the two existing AF requests contains information (for example, as defined in the TS
[00153] [00153] In a second scenario, the AF may request the correlation of its current request with a request for
[00154] [00154] In a third scenario, the AF may request joint UP optimization for traffic from two or more UEs (or one or more UE groups), providing all detailed information (for example, as defined in TS 23.501, section 5.6.7) on traffic from UEs (or groups of UEs) within a current AF request. There are two sets of information (for example, as defined in TS 23.501, clause 5.6.7), one for each of the UEs (or groups of UEs) in the AF request. In addition, the AF request may include a correlation indication for use in the joint optimization of PU.
[00155] [00155] In the three scenarios above, the correlation indication for use in the joint optimization of UP may include bridge requirement information described elsewhere in this document.
[00156] [00156] In the three scenarios above, the UPs, UP paths or UPFs for the traffic of the UEs (or groups of UEs) can be selected or re-selected together according to the requests of AF. The current AF request (for correlation) can indicate whether the UPs can be connected directly to the main 3GPP network (for example, via a bridge link between UPFs or a bridge UPF), or whether the UPs can be indirectly connected via application locations. If direct connection is allowed, the end-to-end UP path optimized together may or may not include the application location (s), depending on the quality of the interconnection of the application locations.
[00157] [00157] When application locations can be included in the end-to-end path, there are at least two possible cases. In the first case, only one application location (the bridge application) is included in the end-to-end path. In a second case, two or more application locations (bridge interconnect applications) are included in the end-to-end path. In this second case, one or more application locations are selected from a plurality of potential application locations specified in each of the two AF requests (for example, as in the first and second scenarios above) or in the AF request (for example , in the third scenario above) for the corresponding traffic. In the first case, the selected application location may belong to the intersection of sets of potential application locations specified in the two AF requests. In the second case, the two or more selected application locations can be interconnected, and the interconnection information (for example, connectivity, cost, quality, QoS properties such as delay, throughput, etc.) can be provided by AF to network for application location selection purposes. The AF request (for correlation purposes) may include the application location interconnect information. Alternatively, the application location interconnect information can be pre-configured in one or more of the PCF, SMF, NEF, UDM, UDR or network repository function (NRF), for example by the OAM system (Operation, Administration and Maintenance ). The interconnection can represent logical connectivity between two application locations. The AF request (for correlation purposes) can indicate whether or not a common or single application location should be selected. The AF request can indicate this implicitly by specifying that there is no interconnection between any pair of applications to enforce this single application location selection.
[00158] [00158] In some modalities, each application location can be associated with a weight in the application location, which may reflect the load or capacity of the application location. This weight can be provided by the AF in the AF request, when the AF requests to influence traffic routing. The weight can be used by the SMF, along with other information, such as one or both: UP topology information; and application location interconnection information, in order to make the application location (re) selection decision. This (re) location decision is made when SMF performs the (re) selection of the UP path.
[00159] [00159] Modalities of the present invention can be applied to IMS services or IMS applications. When IMS media between two UEs (for example, for voice / video calling) does not need to traverse the IMS media plan, an IMS server can act as AF and request that direct P2P traffic be routed without involving the IMS media plan (that is, without involving any application server or application location). The P2P traffic in this case can be bridged before crossing the IMS media plan. If the IMS media needs to traverse the IMS media plan (for example, for some special IMS-related functionality), the IMS server can request that P2P traffic be routed through the application servers (for example, IMS media servers). Application servers are deployed near the edge of the service PLMN. If the necessary IMS-related functionality is provided natively by the UPF, direct P2P traffic routing may be sufficient. The IMS server can determine what type of P2P traffic routing is required. Application server / location interconnect information can include IMS media plan topology information, for example, indicative of how the media servers are interconnected.
[00160] [00160] The P2P UP optimization features, as described here, are applicable to scenarios for which two UEs are being served by the same PLMN. The service PLMN may or may not be the HPLMN for one or both UEs.
[00161] [00161] In some modalities, the service call session control function (S-CSCF) of one of the two peer UEs can act as AF, initiating the influence of AF in the traffic routing, as described in 3GPP TS 23.501 v15 .0.0, section 5.6.7. If the S-CSCF is in the UE service PLMN, the S-CSCF can act as the AF. Otherwise, the S-CSCF can interact with a proxy call session control function (P-CSCF) on the visited IMS, which acts as AF on behalf of the S-CSCF to initiate the influence of AF.
[00162] [00162] In some modalities, each S-CSCF performs AF influence operations individually, but indicates the correlation with the other AF influence. This is so that the two AF influences are considered together for the management of PU. In some embodiments, multiple S-CSCFs can interact to exchange AF transaction ID information for use in correlation operations. In PLMN, the PCF or SMF can be pre-configured with the interconnection information for some or all of the application servers / locations.
[00163] [00163] In some embodiments, UE S-CSCFs that have P2P traffic can interact to exchange application service location information (whether or not application servers should be used or visited, and which application servers are suitable candidates ). One of the S-CSCFs initiates the influence of AF using the information. In some embodiments, the interconnection information for interconnecting these application servers can be pre-configured on the two S-CSCFs. This mitigates the need to exchange this interconnection information dynamically.
[00164] [00164] Modalities of the present invention can be applied to support vehicle for all (V2X) communication, which was previously proposed and which can be based on wireless location area networks. The V2X can, for example, be used to support vehicle platoons. In the platoon, vehicles are grouped into coordinated platoons, for example, which accelerate and brake together to maintain the distance between vehicles. The point-to-point communication bridge can be used to support and enhance communication between multiple vehicles in this case.
[00165] [00165] In the case of using a platoon of V2X vehicles, as mentioned above, the leading vehicle may need to carry out vehicle-to-vehicle (V2V) communication with the other vehicles in the platoon. This may be necessary to instruct other vehicles to apply braking or accelerate in order to maintain a nominal inter-vehicle distance and to avoid collisions or maintain fuel efficiency. This delay-sensitive V2V communication can occur dynamically in a one-to-many way (asymmetric communication). If the direct wireless communication link between vehicles is not available or is only available to part of the platoon, V2V communication may need to cross the network infrastructure (main network). Even though the direct wireless communication link between vehicles is available, V2V communication through the infrastructure can occur in parallel to ensure reliability. Efficient user plan paths are required to meet the delay requirements for this use case.
[00166] [00166] Modalities of the present invention therefore correlate the PDU sessions of the platoon vehicles to carry out the joint optimization of the UP path for the correlated PDU sessions. For example, this may involve selecting a common UPF for these PDU sessions. This can be accomplished by improving the influence of AF on the traffic routing described in 3GPP TS 23.501 v15.0.0, section 5.6.7. The related sessions of the
[00167] [00167] In some of these modalities, the AF (which can be a V2X application controller) makes a request to correlate the PDU sessions of a group of UEs. AF can indicate which UE is the primary UE or the group leader (for example, the leading vehicle in the case of platoon use). The AF request is sent to the PCF, which generates policies sent to the SMFs that serve the PDU sessions. SMFs operate together through interaction to (re) select UP paths for PDU sessions, in order to provide efficiency on the path between the UEs.
[00168] [00168] FIGS. 12A and 12B illustrate call flows related to joint UP path optimization, in accordance with modalities of the present invention, such as modalities that support V2X vehicle platoon.
[00169] [00169] In some modalities, for joint UP path optimization, a single, common SMF manages the PDU sessions. In some of these modalities, a UE includes an application ID in its session request. The application ID indicates the application for which the PDU Session is to be used for, for example, a V2X vehicle platoon application. The AMF selects the appropriate SMF according to the application ID, S-NSSAI group information and EU group information and operator policy. The S-NSSAI is provided by the UE (along with the application ID) in the session request. UE group information is obtained by the UDM's AMF, providing the UE's identifying information to the UDM. The operator policy is obtained from the PCF. If the operator policy indicates that a specific SMF should be selected, that SMF is selected. If the operator policy does not specify a specific SMF, the AMF selects an SMF and informs the PCF of the identity of the selected SMF. This information will be provided to other AMFs as part of the operator policy, so that the same SMF is selected for the relevant PDU sessions.
[00170] [00170] The common SMF obtains policies (indicating the correlation of PDU sessions) from the PCF, jointly optimizes the UP paths of the correlated PDU sessions, and configures direct traffic routing / routing between the UP paths to allow communication asymmetric. Traffic routing / routing can be configured to allow multicast or non-multicast. In the case of multicast, UL traffic is directed / routed to all other UP paths. In the case of multicast, UL traffic is directed / routed to any of the other selected UP paths. In some modalities, UL traffic can be directed / routed to multiple selected UP paths. Which UP paths are directed / routed for UL traffic can be updated dynamically by PCF through SMF, or by SMF according to the current load on the network, or according to the mobility of the destination UE, or both.
[00171] [00171] In some modalities, for the joint optimization of the UP path, multiple SMFs cooperate to manage the correlated PDU sessions. In a first modality for multiple cooperating SMFs, the SMF associated with the primary UE or the leading UE (for example, in the case of the V2X platoon) acts as a master SMF, while the other SMFs act as slave SMFs. Slave SMFs deliver UP path selection tasks to the SMF master. The transfer can be a complete transfer, so that the SMF master becomes the service SMF. Alternatively, the handover can hand over the decision making task to the master SMF, to provide a single point of decision making, while other tasks, such as setting up the UPF, are still performed by the slave SMFs. An identification of which UE is the leading UE or the primary UE can be indicated by the AF in the AF request. The SMF associated with the primary or leader UE can be the SMF that is serving traffic from that UE, as identified in the AF request.
[00172] [00172] The AF request includes an identification of the UE to which the AF request is related, the (UE) traffic to which the AF request is related, or both. PDU sessions can be identified based on this information in the AF request. Modalities of the present invention comprise correlating the PDU Session (s) identified for joint UP optimization.
[00173] [00173] In some modalities, the PCF directly indicates which of a plurality of SMFs should function as a master SMF and, optionally, SMFs that should function as slave SMFs. In other modalities, the PCF indirectly indicates which SMF should function as an SMF master. For example, the PCF may indicate that a specific UE is a primary UE (for example, the leading UE in a platoon application). The SMF that manages the PDU session associated with primary UE traffic, as defined in the AF request, is automatically determined and selected as the master SMF.
[00174] [00174] FIGS. 12A and 12B illustrates a call flow to implement the aforementioned modality for joint UP path optimization involving multiple cooperating SMFs, in particular where a first SMF (SMF-1 1222) acts as a slave SMF and a second SMF (SMF-2 1224) acts as the SMF master. The operations illustrated in FIGs. 12A and 12B are described below. In operation (1200), AF 1236 sends the AF request to PCF 1228. The AF request includes PDU session correlation information, as described elsewhere in this document. The AF request can indicate which UE should be considered the primary UE. The PDU session associated with the primary UE traffic specified in the AF request is considered the primary PDU session. PCF 1228 can consider the service SMF of this primary PDU session as a master SMF. The PCF generates PCC rules based on the content of the AF request.
[00175] [00175] In operation (1201), PCF 1228 provides PCC rules, related to the AF request, to the SMF master (SMF-2 1224). Operation (1201) includes the following sub-operations. In suboperation (1201a), SMF master 1224 obtains the PCC rules from PCF 1228. The PCC rules include the PCC rules generated based on the AF request in operation (1200). This can occur during the establishment of a PDU session, when the SMF obtains operator policies from the PCF. This can also occur in the form of policy update notification during PDU session modification. For example, this can happen when SMF master 1224 interacts with PCF 1228 to obtain the policy related to P2P traffic when informed about the detection of P2P traffic by an UPF. The SMF master 1224 can then apply the CCP rules to optimize the user plan path
[00176] [00176] In operation (1202), SMF slave 1222 initiates SMF relocation, PDU session delivery or a combination thereof.
[00177] [00177] Operation (1202) can be triggered by operation (1201). For example, operation (1202) can proceed in response to the sub-operation (1d) that occurs. In this case, suboperations (1202a), (1202b) and (1202c) are optional and can be omitted. If operation (1202) is not triggered by operation (1201), sub-operations (1202a), (1202b), (1202c) may be required. In more detail, suboperations (1202b) and (1202c) can be used to discover the SMF master and the primary PDU session, similar to suboperations (1201b) and (1201c) (which are to discover slave SMF and slave PDU session ). The PCC rules obtained in the suboperations (1201a) and (1202a) can be the PCC rules generated based on the AF request for correlation of the PDU session in operation (1200).
[00178] [00178] In operation (1203), SMF master 1224 obtains operator policies from PCF 1228. This step can be used to validate the SMF / PDU Session Transfer relocation requested in the operation (1202). Operation (1203) is optional if SMF master 1224 has already obtained a valid operator policy (for example, PCC rules), for example, through operation (1201a) or OAM system configuration. In operation (1204), SMF master 1224 obtains information indicative of interconnection between application locations and cost, quality (such as performance or QoS parameters) and / or weight associated with the interconnection of UDM 1226 or UDR. This step is optional if the operator policy (PCC rules) generated based on the AF request in operation (1200) indicates that the P2P path does not need to involve application localization. In operation (1205), SMF master 1228 determines (for example, selects or selects again) the P2P path, possibly including applications (for example, required application servers in selected locations).
[00179] [00179] In operation (1206), SMF master 1224 notifies AF 1236 of selected location (s) in the P2P path if the request for AF in operation (1200) indicates signature for this notification. This is an advance notification, as it happens before the configuration of the P2P path. In operation (1207), the SMF master sets the P2P path. Operation (1207) includes the following sub-operations. In suboperation (1207a), SMF master 1224 configures (or initiates configuration) the UP-2 1232, including the behavior of directing traffic on the UPFs in the UP-2. In suboperation (1207b), SMF master 1224 configures or initiates the configuration of the UP-1 1230, including the behavior of directing traffic on the UPFs on the UP-1. Suboperation (1207b) is optional if the SMF master is not able to configure UP-1 (for example, if the SMF master is in a different administrative domain and is not authorized to do this configuration) or if the SMF slave does not deliver completely the slave PDU Session to the SMF master (ie, full reallocation of the SMF service to the slave PDU Session).
[00180] [00180] In operation (1208), SMF master 1224 notifies SMF slave 1222 of the P2P path decision (for example, which UPF (s) should be added or removed from UP-1 1230, at which location of UP-1 application is connected (if any) and connected through which UPF, which UPF on UP-1 connects to UP-2) related to UP-1. SMF master 1224 can inform SMF slave 1222 about whether the UP-1 configuration has been performed (that is, whether suboperation (1207b) has been performed). In operation (1209), SMF slave 1222 configures the UP-1 1230, including the behavior of directing traffic on the UPFs on the UP-1, if this has not yet been performed (for example, as indicated in operation (1208)) . In operation (1210), SMF slave 1222 informs SMF master 1224 that the UP-1 configuration is complete. This operation (1210) is optional if the UP-1 configuration is performed by the SMF master 1224 in the operation (1207b). In operation (1211), SMF master 1224 notifies AF 1236 of the application location selected on the P2P path if the AF request in operation (1200) indicates a signature for such notification. This is a late notification.
[00181] [00181] In a second modality, which supports multiple SMFs that cooperate to manage PDU sessions for joint UP path optimization, the PCF directs joint UP optimization. This can be done, for example, in support of direct routing. The PCF selects or reselects the PSAs (PDU session anchors) from each of the correlated PDU sessions used to connect the UP paths of the correlated PDU sessions and informs each of the SMFs involved (the service SMFs of the Correlated PDUs) of selection or re-selection. SMFs optimize the UP paths for the correlated PDU sessions served by them according to the PSAs selected by PCF and configure the traffic routing in the PSA to allow direct traffic routing between the UP paths. In the state of the art, PSA is typically a UPF that connects the UP path to the data network. However, in the modalities of the present invention, when two UP paths are directly connected
[00182] [00182] In some modalities, to support indirect routing (for example, through DN or application location) instead of direct routing (without involving DN or application location), PCF selects or reselects application locations for correlated PDU sessions, instead of selecting or re-selecting PSAs in case of direct routing. Next, SMFs optimize the UP paths according to the location (s) of applications selected by PCF.
[00183] [00183] FIG. 13 illustrates a procedure for relocating PCF, according to the modalities of the present invention, in which the source PCF (S-PCF) 1324 triggers the PCF relocation to a target PCF (T-PCF) 1326. The call flow illustrated in FIG. 13 proceeds as follows. In operation (1301), AF 1330 sends an AF request (for PDU session correlation / P2P UP optimization purposes) to the main network (for example, 5GC). The AF request is carried over to the current PCF (S-PCF) 1324 of the PDU Session related to the AF request. In operation (1302), S-PCF 1324 identifies that the AF request is related to a peer PDU Session whose UE is identified using an IP address or some other identifier, such as a GPSI (Generic Public Subscription Identifier). S-PCF 1324 also identifies that the even PDU Session (or the associated UE) is the primary PDU Session (for example, associated with the primary UE or the leading UE). The S-PCF 1324 subscribes to receive the service PCF for that even PDU Session, providing the IP address or UE identifier for a 1328 Link Selection Function (BSF). BSF 1328 maintains the information link between the session PCF and PDU, that is, indicating which PCF is serving in which PDU session. The S-PCF 1324 can also supply the S-NSSAI and / or DNN and / or application ID (included in the AF request) to BSF 1328. In operation (1303), BSF 1328 notifies the S-PCF 1324 with respect to to the PCF link information, which indicates the service PCF of the even PDU session (that is, the T-PCF 1326). For example, the indication can include the network address (for example, IP) of the T-PCF or the identifier of the T-PCF. In the event that the even PDU session has not yet been established (and therefore the T-PCF is not yet known), the link information may not be provided immediately after the operation (1302). However, in this case, the link information is provided later
[00184] [00184] To clarify, from the SMF's point of view, the relocation of the PCF refers to a reselection of the PCF. The reselection target is provided by T-PCF 1326 or S-PCF 1324. For the S-PCF point of view, the PCF reallocation is a reallocation in which the PDU Session is delivered to the T-PCF.
[00185] [00185] In the operation (1304) of FIG. 13, S-PCF 1324 tells T-PCF 1326 (via a PCF reallocation request) that PCF reallocation is required or requested. The relocation of the PCF involves the PDU session (that is, the PDU session related to the AF request in operation (1301) and being serviced by the S-PCF) being delivered from the S-PCF to the T-PCF. In this operation, the S-PCF can provide the session-related context for the T-PCF. In operation (5), if the context related to the session was not provided to the operating T-PCF (1304), S-PCF 1324 provides that context to the T-PCF 1326. Otherwise, the operation (1305) can be omitted . In operation (1306), SMF 1322 again selects T-PCF 1326 as the serving PCF. In operation (1307), T-PCF 1326 passes a message to BSF 1328 regarding the update of PCF link information, that is, to indicate to BSF 1328 that T-PCF 1326 is now the service PCF of the PDU session.
[00186] [00186] Operation (1306) of FIG. 13 can proceed as indicated in routine (13A) or routine (13B), as marked in FIG. 13. In the case of the routine (13A), the T-PCF 1326 starts the re-selection of the T-PCF as the service PCF, whereas in the case of the routine (13B), the S-PCF starts the re-selection. Routine (13A) occurs as follows. In sub-operation (1306a), T-PCF 1326 transmits a notification message to SMF 1322, indicative of the relocation of the PCF to the PDU session. The notification can include any of the PDU session IDs, the EU IP address allocated to the PDU session, the T-PCF identifier and the network address (for example, IP address) of the T-PCF. Then, SMF 1322 again selects T-PCF 1326 as the service PCF for the PDU session. SMF 1322 can update locally that T-PCF is the service PCF for the PDU session, and T-PCF can provide the
[00187] [00187] The routine (13B) occurs as follows. In sub-operation (1316a), S-PCF 1324 transmits a notification message to SMF 1322, indicative of the relocation of the PCF. The notification can include any PDU session ID, EU IP address allocated to the PDU session and information indicative of the T-PCF's identity (for example, network address or T-PCF identifier). The SMF then re-selects the T-PCF as the service PCF for the PDU session. In sub-operation (1316b), SMF 1322 sends a message to T-PCF 1324 with a message confirming the relocation of the PCF. As above, confirmation can indicate that SMF has taken T-PCF as the service PCF for the even PDU session and T-PCF will later interact with SMF as the service PCF for the PDU session. The T-PCF records the mapping between the PDU session and the SMF. In sub-operation (1316c), SMF 1322 notifies S-PCF 1324 that the PCF reallocation is complete.
[00188] [00188] FIG. 14 illustrates another PCF relocation procedure, in which the T-PCF activates the S-PCF to perform the relocation, according to another embodiment of the present invention. FIGS. 13 and 14 together illustrate the relocation of PCF as triggered by the S-PCF or the T-PCF. The procedures in each of FIGs. 13 and 14 allow alternatives so that the S-PCF or T-PCF can initiate a reselection part of the procedure.
[00189] [00189] The call flow illustrated in FIG. 14 proceeds as follows. Various details in FIG. 14 can be the same as in FIG. 13. In operation (1401), AF 1430 sends an AF request (for the purpose of PDU session correlation / P2P UP optimization) to the main network (for example, 5GC). The AF request is carried over to the current service PCF (T-PCF) of the primary PDU Session related to the AF request. This PCF will be the target PCF of the PCF in the relocation. In operation (1402), T-PCF 1426 identifies that the AF request is related to a peer PDU Session whose UE is identified using an IP address or some other identifier, such as a GPSI. T-PCF 1426 also identifies that the even PDU Session (or the associated UE) is the primary PDU Session (or primary UE or leading UE). The T-PCF 1426 subscribes to receive the service PCF for that even PDU session, providing the IP address or the EU identifier for a 1428 Link Selection Function (BSF). The T-PCF can also provide the S-NSSAI and / or DNN and / or application ID (included in the AF request) to BSF. In operation (1403), BSF 1428 notifies T-PCF 1426 regarding PCF link information, which indicates the service PCF of the even PDU session (that is, the S-PCF). For example, the indication can include the network address (for example, IP) of the S-PCF or the identifier of the S-PCF. In the event that the even PDU Session has not yet been established (and therefore the S-PCF is not yet known), the link information may not be provided immediately after the operation (1402). However, in this case, the link information is provided later.
[00190] [00190] In the operation (1404) of FIG. 14, T-PCF 1426 tells S-PCF 1424 (via a PCF reallocation request) that PCF reallocation is required or requested. Reallocating the PCF involves delivering the even PDU Session from S-PCF 1424 to T-PCF 1426. In operation (1405), S-PCF 1424 delivers the even PDU session to T-PCF 1426. This can involve providing the context related to the session to the T-PCF. In operation (1406), SMF 1428 again selects T-PCF 1426 as the service PCF for the even PDU session. In operation (1407), T-PCF 1426 passes a message to BSF 1428 regarding the update of the PCF link information.
[00191] [00191] Operation (1406) of FIG. 14 can proceed as indicated in routine (14A) or routine (14B), as marked in FIG. 14. In the case of the routine (14A), the T-PCF 1426 starts the re-selection of the T-PCF as the service PCF, while in the case of the routine (14B), the S-PCF 1424 starts the re-selection . Routine (14A) occurs as follows. In sub-operation (1406a), T-PCF 1426 transmits a notification message to SMF 1422, indicative of the PCF's reallocation for the even PDU session. The even PDU session is the session that is currently being served by the S-PCF (and related to the AF request in operation (1401)) and that must be reallocated to the T-PCF. The notification can include any of the PDU session IDs, the EU IP address allocated to the PDU session, the T-PCF identifier and the network address (for example, IP address) of the T-PCF. Then, SMF 1422 again selects the T-PCF as the service PCF for the PDU session (peer). The SMF can update locally that the T-PCF is the service PCF of the PDU session (peer) and the T-PCF can provide the T-PCF identifier and / or the T-PCF network address to the SMF. In sub-operation (1406b), SMF 1422 responds to T-PCF 1426 with a message confirming the relocation of the PCF. Confirmation may indicate that the SMF has taken the T-PCF as the service PCF for the even PDU session. The T-PCF will later interact with the SMF as the service PCF for the PDU session (peer). Subsequently, the SMF uses the T-PCF as the service PCF for the even PDU Session.
[00192] [00192] The routine (14B) continues as follows. In sub-operation (1416a), S-PCF 1424 transmits a notification message to SMF 1422, indicative of the PCF's reallocation for the even PDU session. The notification can include any PDU session ID, EU IP address allocated to the PDU session, and information indicating the identity of the T-PCF (for example, network address or T-PCF identifier). The SMF 1422 then re-selects the T-PCF as the service PCF for the PDU session. In sub-operation (1416b), SMF 1422 sends a message to T-PCF 1426 with a message confirming the relocation of the PCF. As above, confirmation can indicate that SMF has taken T-PCF as the service PCF for the even PDU session and T-PCF will later interact with SMF as the service PCF for the PDU session. The T-PCF records the mapping between the PDU session and the SMF. In sub-operation (1416c), SMF 1422 notifies S-PCF 1424 that the PCF reallocation has been completed.
[00193] [00193] FIGS. 13 and 14 support the reallocation of the function of serving the PCF for a PDU session, from a source PCF to a target PCF. This can be done, for example, in response to an AF request, and can be done as part of a path optimization, for example. The AF request can indicate which UE (or PDU Session) is the primary UE (or primary PDU Session) and thus can indicate which PCF should be the master PCF. This can be done in a similar way to the concept of SMF master in other modalities, such as the modality illustrated in FIGs. 12A and 12B. The master PCF can be considered the target PCF in relocating PCF to PDU sessions from non-primary UEs (or non-primary PDU sessions) specified in the AF request. The AF request can be received at the source PCF or at the target PCF and that receiving PCF can trigger the relocation. PCF reallocation can be used, for example, to allow a master (target PCF) to act as a single decision point and to generate or provide policy decisions (in the form of CCP rules) for multiple PDU sessions together. Policy decisions are provided to the SMFs served from these PDU sessions.
[00194] [00194] In some modalities, and as an example, the relocation of PCF may comprise the use of a BSF to monitor and provide PCF link information and perform the reallocation only after receiving PCF link information. In several modalities, the PCF reallocation operation is coordinated with other associated operations, such as the reallocations of other PCFs involved in the same P2P session (or the same P2P path in optimization). In this case, the relocation of the PCF can be prepared, but not implemented, until a specified time, for example, after receiving confirmation that other associated operations have also been performed or should be performed at the specified time. Multiple operations, including the relocation operation (for example, multiple PCF relocations) can be coordinated and performed simultaneously, waiting for confirmation that all the different operations are ready to be performed, triggering the relocation operations to be performed simultaneously after receipt of such confirmation.
[00195] [00195] In some modalities, the NEF (network capacity exposure function) can select a PCF as the master PCF if the NEF is used to transport the AF request to the PCF's AF. This can provide an alternative way of determining a primary or master PCF, rather than relying on an indication, in the AF request, of a primary UE or a primary PDU session. When the NEF selects the PCF in this way, the information (for example, identifier or network address (for example, IP address) of the master PCF selected by NEF) can be provided by NEF to the PCF together with the contents of the AF request. The PCF can then associate this PCF information with the PCC rules generated based on the content of the AF request. Alternatively, the information can be included in the CCP rules. Subsequently, the S-PCF or T-PCF can trigger the PCF reallocation as described, for example, in FIGs. 13 or 14, according to the master PCF information, as specified in the CCP rules.
[00196] [00196] FIG. 15 illustrates P2P path optimization, in accordance with an embodiment of the present invention. The call flow illustrated in FIG. 15 proceeds as follows. In operation (1501), PCF 1526 is triggered to optimize a P2P path. Operation (1501) can comprise one or more alternative drives, illustrated as sub-operations (1501a), (1501b) and (1501c). Therefore, one or two of these sub-operations can be omitted in some ways. In more detail, in the sub-operation (1501a), the drive is received as an AF request, which is transported to the PCF from AF 1528 through NEF and / or UDR, for example. The AF request can be a new AF request or an update to an existing AF request. The AF request can be a PDU session correlation request for P2P path optimization, as described elsewhere in this document. Modes of the present invention comprise transmitting, receiving or manipulating the AF request, or a combination thereof. In the sub-operation (1501b), an internal trigger occurs, such as overload or failure event related to the UPF or the application location. In the suboperation (1501c), a UE mobility event occurs and, when the PCF subscribes to UE mobility events, SMF 1524 notifies events relevant to PCF 1526. For example, the UE mobility event can be triggered when the UE enters or leaves an area of interest specified by the PCF and the notification may indicate the same. In some modalities, the mobility event notification can be sent from the AMF, for example, when the PCF signs this AMF notification. FIG. 15 illustrates the use of a master PCF to generate joint policies for correlated PDU sessions to facilitate P2P path optimization.
[00197] [00197] In the operation (1502) of FIG. 15, PCF 1526 selects or reselects P2P bridges for use in supporting one or more correlated PDU sessions. The selection of the P2P bridge is described in detail elsewhere in this document. The PDU session correlation information is provided by AF 1528 through an AF request, which may be the AF request in operation (1501) or an AF request received by the PCF at an earlier time.
[00198] [00198] As will be readily understood in view of the present disclosure, a P2P bridge may comprise a UPF commonly shared by UPs of correlated PDU sessions, a link between UPFs in UPs of correlated PDU sessions, an application location shared by sessions of Correlated PDUs, a link between application locations of correlated PDUs sessions; in this case, the link is in the DN or a combination of them.
[00199] [00199] In the operation (1503) of FIG. 15, PCF 1526 provides the P2P bridge information to the relevant SMFs 1524 via a policy update message. The information can be provided in the form of CCP rules generated based on the content of the AF request in operation (1501a). The operating policy update (1503) can indicate, for each one or more sessions, which bridges should be used for each session. In operation (1504), SMF 1524 performs the (re) selection of UP with respect to the P2P bridge information received from the PCF and other information, as defined in 3GPP TS 23.501 v15.0.0, section 6.3.3, and configure the path of UP, including the configuration / update of the traffic routing behavior of the UPF 1522, for example, for routing / delivery of DLP P2P traffic. In operation (1505), SMF 1524 notifies PCF 1526 that the UP and P2P bridge on the UP side is ready (for example, for DL traffic). In operation (1506), PCF 1526 awaits indications that the UP and P2P bridge on the UP side of one or more relevant sessions of the even PDU is ready. Upon receiving these indications, in operation (1507), PCF 1526 notifies SMF 1524 that the P2P bridge is ready (for example, for UL traffic). In operation (1508), SMF 1524 configures / updates traffic routing on the UPF, for example, to support UL P2P traffic.
[00200] [00200] The P2P bridge information provided in operation (1503) of FIG. 15 may include information (for example, ID or network address) indicative of a UPF related to the P2P bridge. It can be the UPF that forms the bridge (in the case of a UPF-based bridge) or connects to the bridge (in the case of a bridge based on the application location). The information can include traffic direction information to be configured in the UPF to support the P2P bridge.
[00201] [00201] In the case of a UPF-based bridge, tunneling can be applied to the bridge. In that case, the UPF-related tunnel configuration can be provided as part of the bridge information for the relevant SMF, which then configures the UPF tunnel configuration.
[00202] [00202] Operations (1505), (1506), (1507) and (1508) in FIG. 15 are used to coordinate the P2P bridge operation of SMFs and / or UPFs from multiple different UPs. For example, when a bridge between two or more UPs must be established, the configuration is performed for each UP. When confirming that the configuration has been completed for all UPs, the traffic direction is carried out in a way that implements the bridge. This coordination is used to prevent directional traffic from the UP towards a bridge before a UP on the other side of the bridge is fully configured to accept and handle the bridge traffic. PDU sessions can be managed independently by their own SMFs, so that coordination may be necessary.
[00203] [00203] In view of FIG. 15, embodiments of the present invention provide a PCF, or method of operating a PCF, in which the PCF performs P2P bridge selection, reselection, or both. The selected bridge can be created to connect two, three or more PDU sessions in a specific way and can also involve one or more application functions or application servers, service function chains, etc., where appropriate. The PCF can perform this function in support of an application, for example, as indicated in an application role request. AF can provide the PCF with an indication of two or more correlated PDU sessions. The PCF can, in response, bridge the gap between these PDU sessions or other joint path optimization. The PCF can also target one or more SMFs, for example associated with different user plans and / or different PDU sessions, to implement one or more different parts of the selected bridge. This direction can be provided in the form of policy updates. The PCF can further coordinate the bridge operation, waiting for confirmation that all different parts of the selected bridge are ready and triggering the UPFs to direct traffic in support of the bridge only after receiving this confirmation. The implementation of changes in traffic direction for multiple UPFs can therefore be carried out simultaneously.
[00204] [00204] Although the operation of the PCF is described above with respect to the bridge of correlated PDU sessions (with or without application server intermediation), the PCF can more generally perform joint path optimization of the correlated PDU sessions. AF can provide correlation information and PCF can perform joint path optimization based on the information provided and then directly implement the optimized paths together. Correlation information is passed from AF to PCF and used for path configuration (and associated traffic routing configuration) by SMF and UPF.
[00205] [00205] Modalities of the present invention provide an SMF that cooperates with the PCF as described above, and also as illustrated in FIG. 15. The SMF is configured to receive PCF policy update information and perform one or more of the following: select, reselect, configure and reconfigure your managed UP based on the policy update. Selection, re-selection, configuration or reconfiguration supports joint path and / or bridge optimization. Configuration or reconfiguration may involve targeting an underlying UPF to target traffic in order to implement joint path and / or bridge optimization. The SMF can still be configured to notify the PCF when the configuration or reconfiguration is ready to deploy, but refrain from implementing the configuration or reconfiguration until a confirmation message is received from the PCF. The implementation of the configuration or reconfiguration can be carried out (for example, substantially immediately or at a specified future time) after receiving the confirmation message. Implementing the configuration or reconfiguration may involve targeting the UPF to implement the previously configured traffic targeting.
[00206] [00206] Furthermore, with regard to the modalities of the present invention, and the content of the control signal in particular, information about the interaction between SMFs can be provided. This information can be provided, for example, by one SMF to the other during this interaction. The information can include UP path information, structural UP path information, or both. The information can include bridge endpoint information, for example, exchanged between SMFs. The information can include traffic filtering information, traffic routing information, or both. In some embodiments, traffic filtering information is sent only to the source SMF or similarly only to the SMFs expected to handle uplink traffic.
[00207] [00207] In various modalities, for example in relation to FIG. 4, NEF maps the information provided in the AF request to the information used internally on the main network. The NEF can map the target PDU session information to the target PDU session ID by contacting an NRF (Network Repository Function) or a unified data manager (UDM). In this case, the service SMF of the target PDU session can register the mapping in the NRF or UDM. Additionally or alternatively, the NEF can map the information from the source PDU session to the source PDU session ID, for example, in the case of an ongoing PDU session. This mapping can be done by contacting the NRF or the UDM. In this case, the service SMF of the source PDU session can register the mapping in the NRF or UDM. In several modalities, the NEF provides the mapped information to the PCF for use in generating CCP rules. The NEF can provide the information to the PCF, for example, through a unified data repository (UDR).
[00208] [00208] In some modalities, the PCF provides an update of the CCP rules for the service SMF of the source PDU session. The SMF in service can be identified by means of UDM or NRF, if not known locally by the PCF, using the information from the source PDU session. If the target UPF is not mapped by the NEF, the PCF can perform a necessary mapping using the information from the target PDU session obtained from the AF request. In this case, the SMF may need to register the UPF with the PCF. Alternatively, the PCF can perform a mapping to the service SMF of the target PDU session. As noted above, a CCP rule can include traffic filtering information, traffic routing information, and an indication of a target UPF or target SMF involved in the bridge. In several modalities, if the source UPF and the target UPF are not connected at the transport layer, no corresponding PCC rules will be generated.
[00209] [00209] In some modalities, the service SMF of the source PDU session configures the source UPF with the information of traffic direction. In other embodiments, if the PCC rule includes target SMF information instead of target UPF information, the SMF interacts with the target SMF to discover the target UPF information. If the source UPF and the target UPF are not connected, the SMF will not configure the P2P traffic routing operation. In this case, traffic will be processed at the UPF in a standard manner (for example, state of the art). An error or event signal can be generated in response to this situation.
[00210] [00210] In some modalities, the UPF source detects UL traffic according to the flow decryptor and processes the traffic according to the traffic direction information. The source UPF forwards processed traffic to the target UPF. The target UP receives and handles forwarded bridge traffic as if it came from the application server and forwards traffic to the destination UE through DL.
[00211] [00211] In some modalities, the PCF identifies the source and target SMF and obtains the UP path information from them. The PCF determines the parameters of (re) configuration of UP and provides these parameters together with the rules of the PCC, including information of (re) configuration of UP, such as (re) selection of UPF and configuration (re) of traffic direction. Alternatively, the PCF can obtain the UP information from a storage function such as a UDM. To support this alternative, SMFs are configured to store and update the UP path information in the storage function.
[00212] [00212] In some modalities, the source SMF requests UP information from the target SMF or from a storage function (for example, UDM, UDR or UDSF). The source SMF can (re) select the UP source according to the target UP information.
[00213] [00213] In some modalities, the PCF indicates that SMF re-selection is necessary. In response, the source SMF redirects the CCP rules that contain the target PDU session ID to the source SMF. The source SMF identifies the target SMF and requests UP path information for the target SMF's PDU session. The information is used to determine the (re) configuration parameters.
[00214] [00214] In some modalities, the main network may inform (for example, periodically or upon request) the AF regarding the use of data in connection with this invention. For example, messages indicative of the total number of P2P messages (or the total number of bytes of such messages) redirected by one or more bridges can be provided to the AF. In some embodiments, the AF or AS may initiate or apply (for example, third parties) loading based on this information, if necessary.
[00215] [00215] In some modalities, when the SMF detects a point-to-point scenario involving or requiring a bridge, as described here (for example, based on the rules of the PCC), the UPF reselection can be triggered to allow that the two PDU sessions share the same UPF.
[00216] [00216] In some modalities, as described above, directional paths can be created between RAN nodes to facilitate the bridge. In this case, for clarity, the UPF path can exclude the actual UPF.
[00217] [00217] Modalities of the present invention refer to a method and apparatus that manages UE groups for one-to-many communication (for example, multicast). According to these modalities, a network function, called Group Management Function (GMF), can be provided, which is responsible for managing EU groups (for example, creating, modifying, removing, answering questions about EU groups) and maintain information about UE groups (or context of UE groups), such as group membership, group properties such as IDs, addresses, metadata, information related to individual group members, etc.
[00218] [00218] When an UE interacts with the GMF, the UE sends an EU group management request to the GMF through AMF, and the UE request can be authorized by the GMF according to the signature information (e.g. information on whether the UE is allowed to make such a request).
[00219] [00219] When an AF interacts with the GMF, the AF sends an EU group management request to the GMF directly or via NEF, depending on whether the operator allows the AF to access the network directly, as described in 3GPP TS 23.501 , section 6.2.10. When the NEF is involved, the NEF can authorize the AF request according to the location configuration (for example, AF contract information stored locally, indicating whether the AF can make such a request), if the AF request has not yet been made. authorized.
[00220] [00220] The request can include a requesting UE ID (if the requesting entity is a UE), AF-service-ID (if the requesting entity is an AF, and the AF-service-ID can be used to identify a request AF), DNN (data network name), S-NSSAI. Depending on the purpose of the management, the request may also include the following information.
[00221] [00221] In some ways, to create the Group
[00222] [00222] In some embodiments, to create or modify the UE Group, the request includes identity information (for example, UE IDs (such as GPSI, SUPI) uniquely identifying a UE in the network or UE IDs uniquely identifying a UE in the group security credential (s) (also known as group credentials) and address information (for example, static IP address used by an EU member to communicate with other EU members) of the UEs to be added or removed from the group of EU. In one example, security credentials are intended to authenticate and / or authorize individual EU member (s) to establish a PDU session; they can be provided by the individual member (s)
[00223] [00223] In some modalities, to create, modify or remove or consult the UE group, the request includes information that identifies the UE group (for example, in the form of internal group ID or external group ID). The request may also include information indicating not to notify relevant UEs (for example, members of the UE group impacted by the UE group management operations) about the UE group management operators. When this information is provided in the application, GMF may be prevented from making the notification.
[00224] [00224] In some embodiments, to remove the UE group, the request may include the address of the UE group (which can be used by the UE members of the EU group to send traffic to the UE group as described above). This can occur, for example, if the group's address was allocated to the EU group by GMF during the creation or modification of the EU group.
[00225] [00225] In some embodiments, to consult the EU group, the request includes information that identifies the EU group (for example, EU group ID), the types of information (for example, EU group metadata, information such as IP address or EU member IDs, group EU group address, group-level EU ID and security credentials described above) being queried.
[00226] [00226] The GMF validates the information provided by the entity, for example, EU IDs and manages the EU group according to the information. As a result of the management activities of the UE group, the context of the UE group is created, modified or removed in the GMF, or the information consulted by the entity is identified in the local storage of the GMF and sent back to the entity. The GMF can update the EU group membership information in the UDM for each EU member, if the UDM is a different entity than the GMF. The GMF may include the EU group ID and group address in the reply message sent to the requesting entity.
[00227] [00227] During the creation of the EU group, the GMF may allocate an ID to the EU group, if the requesting entity has not provided an EU group ID for the EU group in the request. The GMF may also allocate a group address (for example, multicast address) to the EU group, for example, if the requesting entity has provided a group address to the EU group in the request. In some embodiments, group address allocation is performed only if an indication of group address allocation or multicast group creation (indicating a request to allocate a group address to the UE group) is included in the request.
[00228] [00228] During the creation or modification (to add an UE to the EU group) of the EU group, the GMF may allocate an EU ID to each EU member, uniquely identifying the EU member in the EU group, if the requesting entity does not provide such a UE ID level group to the UE member in the request. The group-level UE ID can be used to identify the UE groups to which the UE belongs. The group-level EU ID can be unique across multiple EU groups or shared or reused across multiple EU groups. When the UE belongs to multiple UE groups, the same UE ID at the group level can be allocated to the UE for the multiple UE groups. In this case, the group-level UE ID cannot be allocated to other UEs. The group-level UE ID can be seen as or equivalent to identity information related to the UE DN, where the DN (Data Network) is the DN identified by the DNN provided by the requesting entity (ie a UE or a AF) in the request to create an EU group.
[00229] [00229] During the creation or modification (to add EU member (s) to the EU group) of the EU group, GMF can allocate security credentials (s) (also known as group credentials to each member) This can occur if the requesting entity has provided security credentials to the EU member in the request. In some modalities, the allocation can only be performed if a security credential allocation indication (indicating a request for allocation of security credentials). security to the EU member (s) is included in the request. Security credentials can be used to authenticate and / or authorize individual EU member (s) to establish a security session. PDU; they can be provided by the individual EU member (s) to the main network (5GC) as authentication / authorization information (or as part of the authentication / authorization information) for the purpose of hard secondary authentication / authorization before the establishment of a PDU session. In some embodiments, an EU member's security credentials include the EU member's ID, indicating that the security credentials are for the UE.
[00230] [00230] During the removal of the EU group, if the requesting entity includes a group address of the EU group in the request as described above and if the group address has been allocated to the EU group by GMF, the GMF may mark or consider the group's address as recycled or returned. These returned addresses can be reused for a second EU group, for example, allocated to the second EU group, so that UE members from the second EU group can use the group's address as the destination address to send traffic (for example example, multicast traffic or one-to-many traffic) to the second EU group.
[00231] [00231] When an UE group is created, modified or removed, the GMF notifies the UEs affected by the UE group management operations. The EU (s) can be notified about, for example, being added to or removed from the EU group, metadata and / or group ID and / or address of the EU group, their own EU ID at the group level , another group of members of group-level EU ID UEs and their own security credentials described above. For registered UEs, GMF can notify them through an EU configuration update procedure; for unregistered UEs, GMF may notify them during the initial registration procedure performed by the UEs in the future.
[00232] [00232] In response to or in association with the management of the UE group described above, the GMF (for example, in the case of group management initiated by the EU) or an AF (for example, in the case of group management initiated by the AF) can provide policy requirements to PCF to influence traffic routing (for example, to handle unauthorized / unauthorized traffic indicated during EU group management) for a PDU session. In some modalities, an AF or GMF can provide these policy requirements to the PCF regardless of the management of the EU group. AF or GMF (GMF can be seen as acting as AF) can provide policy requirements to the PCF (either directly or through NEF) in the form of a request (for example, request for AF). In the request, the PDU Session can be identified by any of the following: network address, EU ID, EU group ID, DNN, S-NSSAI and unauthorized or unauthorized traffic can be identified by network addresses (for example, MAC address (es), IP address (es) or a group address described above for UE group management. Unauthorized or unauthorized traffic can be traffic that contains network addresses such as source address or traffic containing network addresses as a destination address.The PCF generates policies (ie in the form of CCP rules) based on the policy requirements (ie request) received from the AF or GMF and provides the policies to the SMF for a PDU Session to which the policy requirements apply.The PCF can determine whether the policy requirements apply to the PDU session by checking the information provided by SMF about the PDU session and / or traffic carried by the PDU session, for example DN N, S-NSSAI, UE ID, UE group ID, UE address, application ID (referring to some traffic packet filter), information about packets / traffic (for example, source address in traffic or address of destination in traffic) in relation to UE information (or PDU Session) and traffic information in policy requirements. Policies provided to SMF from the PCF may include information (for example, in the form of a list of permitted or disallowed source network addresses or a list of permitted or disallowed destination addresses) of unauthorized or unauthorized traffic and indicate actions (for example, abandoning traffic) to be taken for unauthorized or unauthorized traffic. The SMF can configure an UPF (such as PDU session anchor UPF (PSA), uplink classifier UPF (UL CL), branch point UPF (BP)) in the UP path of the PDU session to detect and abandon unauthorized or unauthorized traffic, for example by providing the UPF with packet handling instructions (for example, Packet Detection Rules, Forwarding Action Rules), generated by SMF based on the policies.
[00233] [00233] FIG. 16 represents the procedure for managing a UE group at the request of a UE. The procedure can correspond to the modalities described above related to a method and device that manages UE groups for one-to-many communication (for example, multicast). Referring now to FIG. 16: In operation 1601, the UE sends a request to the GMF for management of an UE group. The request is sent to the GMF through AMF. The request may be for the purpose of creating, modifying or removing the UE group, or for the purpose of consulting information on the EU group or the UEs belonging to the EU group. When the request is to create an UE group, in the request, the UE can indicate that the UE group is a multicast group (or that the UE group is created to support one-to-many / multicast communication ). The UE can provide a group address for the UE group in the request. Alternatively, a group address can be allocated to the EU group by GMF after GMF receives the request. The UE can indicate in the request which UEs (for example, identified by a list of UE IDs) belong to the UE group. The UE can further indicate which members of UEs (for example, identified by a list of EU IDs) of the UE group may or may not transmit traffic to the UE group (ie to the other UEs of the group in a mode of multicast or one-to-many, using the group address in traffic as a destination).
[00234] [00234] In operation 1602, GMF authorizes the request. For authorization, GMF can interact with the UDM to identify whether the UE is allowed to send an UE group management request (this information can be stored in the UDM as part of the UE's subscription data). For authorized EU request, GMF validates the requested information. The GMF can interact with the UDM for validation, for example, to verify the UE IDs in the request.
[00235] [00235] In operation 1603, GMF performs the requested EU group management operations according to the information in the request. GMF can allocate an ID to the EU group. The GMF can allocate a group address to the UE group (the group address can be used as a destination in traffic during one to many communications, this causes traffic to be sent to all members of the UEs in the group except the EU sending traffic).
[00236] [00236] In operation 1604, the GMF updates the group membership information for each EU member to the UDM. The GMF can provide the EU group ID and the EU group member EU IDs to the UDM. The UDM can store the UE group ID as part of the subscription data for each individual UE member, for example, identified by the UE ID.
[00237] [00237] In operation 1605, GMF responds to the UE, acknowledging the acceptance of the request. The request includes information that identifies the EU Group (for example, EU group ID). The application may include the address of the EU group. If the request in operation 1601 is to consult the EU Group, the response includes information being consulted.
[00238] [00238] In operation 1606, the GMF notifies relevant EU member (s) of the EU group about EU group management operations, for example, creation, modification, removal. The notification can be sent to the EU (s) through the network control plan, for example, through MFA. Alternatively, the notification can be sent as a payload for a device or app trigger message sent to the EU (s)
[00239] [00239] FIG. 17 represents the procedure for managing an EU group, at the request of an AF. The procedure can correspond to the modalities described above related to a method and device that manages UE groups for one-to-many communication (for example, multicast). With reference to FIG. 17: In operation 1701, the AF sends a request to the GMF for management of an EU group. The request can be sent to the GMF directly or via NEF. If the NEF is involved, the NEF can authorize the request (for example, according to the location setting, such as the AF contract, to verify that the AF is allowed to send an EU group management request) and forward the authorized request to GMF. The request may be for the purpose of creating, modifying or removing the UE group, or for the purpose of consulting information on the EU group or the UEs belonging to the EU group. When the request is to create an UE group, in the request, the AF may indicate that the UE group is a multicast group (or that the UE group is created supporting one-to-many / multicast communication). The UE can provide a group address for the UE group in the request. Alternatively, a group address can be allocated to the EU group by GMF after GMF receives the request. The UE can indicate in the request which UEs (for example, identified by a list of UE IDs) belong to the UE group. The UE can further indicate which members of UEs (for example, identified by a list of EU IDs) from the UE group may or may not transmit traffic to the UE group (ie to the other UEs in the group in a broadcast way) using the group address in traffic as a destination).
[00240] [00240] In operation 1702, GMF validates the information in the request. The GMF can interact with the UDM for validation, for example, to verify the UE IDs in the request.
[00241] [00241] Operations 1703, 1704, 1705 and 1706 are similar or equal to operations 1603, 1604, 1605 and 1606, respectively, of FIG. 16
[00242] [00242] The UE group information (e.g., UE group ID) managed by the GMF can be used to identify UEs or PDU sessions in the AF request in the modalities illustrated in FIGs. 6 to 8 and 12 to 15. In some modalities, GMF can participate in these procedures by acting or behaving like PA.
[00243] [00243] In response to or in association with the management of the EU group described in FIG. 16 or FIG. 17, the GMF (for example, in the case of group management initiated by UE in FIG. 16) or an AF (for example, in the case of group management initiated by AF in FIG. 17) can provide policy requirements to the PCF to influence traffic routing (for example, to handle indicated disallowed / unauthorized traffic during EU group management). In some modalities, GMF or AF may provide these policy requirements to the PCF, regardless of the management of the EU group.
[00244] [00244] The policy requirement is sent from the GMF or AF to the PCF in the form of a request, for example, request from an AF. GMF can act as AF in the procedure. The request (for example, AF request) can be sent directly from the AF or GMF or via NEF (and possibly later via UDR, if the request affects multiple PDU sessions and must be delivered to multiple PCFs) to PCF.
[00245] [00245] The request may include information that identifies unauthorized / unauthorized traffic and information that identifies UE (s) (or PDU sessions).
[00246] [00246] The information identifying unauthorized / unauthorized traffic may be in the form of a list of unauthorized / unauthorized source or destination network addresses (for example, a group address or multicast address described above in the management of EU group). In this case, traffic that contains one of the source network addresses not allowed as a source address or one of the destination network addresses not allowed as a destination address is considered not allowed / unauthorized. The information can also be in the form of a list of allowed / authorized source or destination network addresses. In this case, traffic that does not contain one of the source network addresses allowed as a source address or one of the destination network addresses allowed as a destination address is considered not allowed / unauthorized.
[00247] [00247] The information that identifies unauthorized / unauthorized traffic may also include DNN, S-NSSAI.
[00248] [00248] The information identifying EU (s) (or PDU Sessions) can include any EU ID, EU group ID, EU network address (for example, MAC address, IP address or prefix).
[00249] [00249] The PCF generates policies (CCP rules) based on the policy requirements (ie the request) received from the AF or GMF and provides the policies to the SMF for the relevant PDU sessions. The SMF configures the UPF according to the policies, so that it detects and abandons unauthorized / unauthorized traffic identified in the policies.
[00250] [00250] FIG. 18 illustrates a procedure for abandoning unauthorized or unauthorized traffic, according to an embodiment of the present invention. Referring now to FIG. 18: This procedure may correspond to the above-described provision of policy requirements to the PCF to influence the routing of traffic in response to or in association with the management of UE groups. In operation 1801, the AF or GMF sends a request to the PCF to influence traffic routing. The request includes information that identifies unauthorized / unauthorized traffic and information that identifies UE (s) (or PDU sessions), as described above.
[00251] [00251] In operation 1802, the PCF generates or updates policies based on the request received in operation 1801.
[00252] [00252] In operation 1803, the PCF notifies or provides SMF with the generated / updated policies for a relevant PDU Session (that is, a PDU Session for which the policy requirements or the request received in the operation
[00253] [00253] In operation 1804, SMF configures the PDU Session UPF user plan (an UPF in the PDU Session UP path, such as PSA (PDU session anchor) or UL CL UPF (classifier of uplink), BP UPF (branch point)) to detect and abandon unauthorized / unauthorized traffic, according to the policies received in operation 1803.
[00254] [00254] Modalities of the present invention refer to a method and apparatus that detects and abandons one-to-many traffic (multicast) not allowed in the user plane. According to these modalities, the SMF receives for a PDU Session the GMF information identifying unauthorized / unauthorized traffic, for example, a list of unauthorized / unauthorized source or destination network addresses (traffic that contains an email address). unauthorized / unauthorized source network as a source address is considered unauthorized / unauthorized; traffic containing an unauthorized / unauthorized destination network address as a destination address is considered unauthorized / unauthorized) or information that identifies permitted traffic / authorized, for example, a list of allowed / authorized source or destination network addresses (traffic containing an allowed / authorized network address as source address is considered allowed / authorized; traffic containing a permitted destination network address / authorized as a destination address is considered allowed / authorized).
[00255] [00255] The above receipt at the SMF may occur during the establishment of the PDU session when the SMF interacts with the GMF to authenticate and / or authorize the UE to establish the PDU session and the information that identifies unauthorized / unauthorized traffic ( or allowed / authorized) can be received by the GMF SMF as part of the authentication / authorization results / data or after the establishment of the PDU session when GMF updates the SMF with new results / authentication / authorization data where the information is contained .
[00256] [00256] The SMF may, alternatively, receive information that identifies unauthorized / unauthorized traffic or permitted / authorized traffic from the PCF in the form of PCC rules during the establishment of the PDU session or the modification of the PDU session. This alternative can be as described in detail with reference to FIG. 18
[00257] [00257] The SMF configures the UPF according to the information (that is, information that identifies unauthorized / unauthorized traffic or permitted / authorized traffic) received from GMF or PCF to abandon unauthorized / unauthorized traffic or forward only allowed / authorized traffic.
[00258] [00258] FIG. 19 represents a procedure to allow the UPF to identify and abandon traffic that is not permitted. With reference to FIG. 19: any of the alternatives 19A and 19B can be performed. In alternative 19A: This procedure can, for example, enable UEs that do not belong to an UE group to receive traffic destined for the UE group or disable UEs (which may or may not belong to the UE group) to send traffic destined for the UE group. In operation 1901, the SMF interacts with the GMF to authenticate / authorize the establishment of a PDU session. This step can be optional. In operation 1902, GMF provides results / authentication / authorization data to SMF, which indicates the result of authentication / authorization. The data can include a list of disallowed source or destination network addresses (for example, IP address or prefix). They are used to identify traffic that the PDU session is not allowed to load (in the UL direction or in the DL direction). Alternatively, a list of allowed source or destination network addresses can be included in the data to identify the allowed traffic.
[00259] [00259] In alternative 19B: In operation 1911, the SMF interacts with the PCF to obtain PCC rules related to the PDU Session. The SMF can provide information about the PDU session and / or traffic carried by the PDU session, for example, DNN, S-NSSAI, EU ID, EU group ID, EU address, application ID (referencing some filter packet traffic carried by the PDU Session correspondence), information about packets / traffic (for example, source address in traffic or destination address in traffic) this operation may be optional. In operation 1912, the PCF provides SMF with CCP rules related to the PDU session. The CCP's rules may indicate non-permitted source or destination network addresses (for example, IP address or prefix) or permitted source or destination network addresses (for example, IP addresses or prefixes). This optional operation is similar to operation 1803 in FIG. 18
[00260] [00260] Following alternatives 19A and 19B, in operation 1903, SMF configures the UPF with instructions for handling packages (for example, PDR (packet detection rule), FAR (forwarding action rule)) based on information received from GMF or PCF in operation 1902 or
[00261] [00261] In Operation 1904, and in accordance with the packet handling instructions, the UPF discards / abandons any UL or DL traffic that contains one of the source network addresses not allowed as a source address or one of the destination network addresses not permitted as a destination address or discard / abandon any UL or DL traffic that does not contain one of the permitted source network addresses as a source address or one of the permitted destination network addresses as a destination address.
[00262] [00262] FIG. 20 illustrates a procedure for managing UE groups according to another embodiment of the present invention. The procedure of FIG. 20 is comparable to that of FIG. 16 and that of FIG. 17 The procedure is initiated by a requesting entity (which can be an AF or a UE, as shown in FIG. 16 or can be a network function other than the AF, such as SMF). If the requesting entity is a UE, operations 2001, 2002 of the procedure are similar to operations 1601, 1602, respectively, of FIG.16. If the requesting entity is an AF, operations 2001, 2002 of the procedure are similar to operations 1701, 1702, respectively, of FIG. 17 The 2003, 2004, 2005, 2006 operations of the procedure are similar to operations 1603, 1604, 1605, 1606, respectively, of FIG. 16 or operations 1703,
[00263] [00263] FIG. 21 illustrates an integrated procedure for establishing a PDU session and creating an UE group (for example, a multicast group). Modalities of the present invention provide a method and apparatus for carrying out this integrated procedure. Details of the PDU session establishment procedure can be found in TS 23.502, particularly with respect to Figure 4.3.2.2.1-1 and clause 4.3.2.2. In particular, operation 2101 can be integrated with (or similar to) step 1 in Figure 4.3.2.2.1-1, operation 2102 can be integrated with (or similar to) steps 2 to 5 (SMF selection, request and response Nsmf_PDUSession_CreateSMContext, Subscription / recovery / signature for updates, Nsmf_PDUSession_CreateSMContext Response) of Figure
[00264] [00264] In more detail, in operation 2101, a UE transmits a request to the AMF to establish a PDU session. The request may be part of a request for the creation of an EU group (for example, a multicast group). The request may include the identity information of the UE (for example, group-level EU ID or identification information related to DN received from GMF (as described above) before the current procedure), which can be used by GMF to authenticate / authorize the UE to establish a PDU session in operation 2103. In operation 2102, AMF and
[00265] [00265] In some embodiments, in the procedure for establishing a PDU session, as illustrated in FIG. 21, operation 2103 is performed if the PDU Session is established for an EU member to communicate with other EU members in an EU group managed by the GMF (otherwise, 2103 operation may be optional). When the SMF releases or disables the PDU Session, the SMF notifies the GMF, for example, by sending a notification message to the GMF, that the PDU session is released or deactivated. The notification may include information that identifies the PDU session, for example, PDU session ID or UE network address. In the case of the release of the PDU Session, if the network address of the UE for the PDU Session is allocated by GMF, the notification can include the network address and be used to return the network address to the GMF for reuse (for example , be allocated to another UE). According to the notification, GMF knows that the PDU Session (identified, for example, by the PDU session ID or UE network address) is no longer available to be used to deliver DL traffic originating from a member from the EU group to the UE. Therefore, the GMF knows or is aware of whether the UE has a PDU Session that can be used to deliver DL traffic originating from an EU member of the EU group to the UE. If the UE does not have PDU sessions, the GMF may find the UE inaccessible by other members of
[00266] [00266] In some embodiments, in the procedure of establishing a PDU session with an integrated UE group creation (for example, multicast group), as illustrated in FIG. 21, the UE can provide information (for example, an indication) in operation 2101, indicating whether the UE group is or is not coupled or associated with the PDU Session or depends on the PDU Session. (If the UE group is attached to or associated with the PDU session or is dependent on the PDU session, the UE group can be removed by the network after the session ends). Information can be provided by the UE as part of the PDU Session Establishment request sent to SMF through AMF (operations 2101 and 2102). In that case, SMF can retrieve or extract information from the request and insert the information (either in the original form or in a transformed form) in the integrated request for EU group creation by sending the integrated request for EU group creation to GMF at operation 2103. (For example, information indicating that the UE group is attached to or associated with the PDU Session, or is dependent on the PDU Session, can be transformed or mapped to information indicating not to notify relevant UEs about management operations group of
[00267] [00267] A variety of operations, call flows and procedures have been described above. It should be noted that two or more of the described operations, call flows and procedures, or other resources or modalities, can be combined to arrive at other modalities of the present invention. For example, one or more procedures or resources can be used to support the operation of one or more other procedures or resources. As another example, one or more different procedures or resources can be provided as alternatives for use in different situations, and a procedure (or corresponding network entity) for selecting between alternatives based on the available information can be included.
[00268] [00268] As will be readily understood based on the above, the modalities of the present invention provide an application function configured to send a message indicating whether the user plan (UP) paths of two or more PDU sessions should be selected or re-selected together. This may include PDU session correlation with the goal of P2P UP path optimization, as disclosed here. This may additionally or alternatively include directing P2P traffic,
[00269] [00269] In some modalities, the AF transmits a request carrying the message indicating whether the user plan (UP) paths of two or more PDU sessions should be selected or re-selected together. In some modalities, the AF transmits a request carrying the indication of whether the UP paths of the two or more sessions should be connected or not via an application location. In some embodiments, the AF request includes information indicating a primary PDU session from the two or more PDU sessions or a primary UE (or leading UE) from a group of UEs.
[00270] [00270] As will also be readily understood based on the above, the modalities of the present invention provide a PCF configured to: receive a message indicating whether the user plan (UP) paths of two or more PDU sessions should be selected or re-selected together; and also configured to transmit an instruction to a session management function (SMF) indicating that the user plan (UP) paths of two or more PDU sessions must be selected or re-selected together. The PCF can also be configured to receive an indication of whether or not the UP paths of the two or more sessions should be connected via an application location and, optionally, can be configured to transmit an instruction to a session management function (SMF) indicating that the UP paths of the two or more sessions must be connected via an application location or not. The PCF can also be configured to receive a request loading one or both of: the aforementioned message indicating whether the user plan (UP) paths of two or more PDU sessions should be selected or re-selected together; and indication of whether or not the UP paths of the two or more sessions should be connected via an application location.
[00271] [00271] As will also be readily understood based on the above, the modalities of the present invention provide an SMF configured to: receive an instruction (also referred to as a rule) from a policy control function (PCF), the instruction indicating that the user plan (UP) paths of two or more designated PDU sessions must be selected or re-selected together; and to select or reselect the UP paths of the two or more designated PDU sessions, based on the instructions. This selection or re-selection of the UP path can correspond to the P2P UP path optimization or the direction of P2P traffic, as previously described here.
[00272] [00272] As will also be readily understood based on the above, the modalities of the present invention provide a PCF configured to: receive, from an application function (AF), a message indicating that the user plan (UP) paths two or more PDU sessions must be selected or re-selected together; and select or re-select one or both: user plan functions (UPFs); and application locations, for use in connecting said UP paths from said two or more PDU sessions. The indication that the PDU sessions should be selected or selected again together may correspond to the correlation of the PDU session, as described earlier here. The connection of the UP paths can correspond to the bridge as described earlier in this document. The PCF can be configured to perform said selection or re-selection in response to a trigger. The trigger can be received from a session management function (SMF) or an access and mobility management function (AMF). The PCF can be configured to receive an indication that the UP paths of the two or more PDU sessions must be connected via an application location. The PCF can also be configured, after selection or re-selection, to notify a session management function (SMF) of the selected or re-selected UPFs or application locations. The PCF can be configured to receive a message from a session management function (SMF) indicating that a connection (P2P bridge) related to one of the UP paths is ready and confirming with SMF that the connection is established when related connections all two or more PDU sessions are ready.
[00273] [00273] As will also be readily understood based on the above, the modalities of the present invention provide an SMF configured to: receive an instruction from a policy control function (PCF), the instruction indicative of one or both: a plan User selected or re-selected function (UPF); and an application location and selecting or reselecting the UP path of a PDU session based on the instructions received. The selected or re-selected UP path can include one or both of the selected or re-selected UPF and the application location. The SMF can also be configured to send a message indicating that a connection related to the UP path is ready.
[00274] [00274] It will be readily understood that, throughout the previous discussion, the network features and operations described above may correspond to a method for use in supporting the operation of a communication network, such as a 5G wireless communication network. The method can involve functions implemented by computer, that is, functions implemented by one or more components of computing, communication or memory of the network infrastructure or a combination of them. These components can take various forms, such as specific servers or general purpose computing, communication or memory devices or combinations of them, configured to provide the necessary functionality through virtualization technologies. The method may involve the operation of one or more network components in order to improve the operation of the network. As such, with the communication network seen as an apparatus, the modalities of the present invention can be targeted to improve the internal operations of the communication network.
[00275] [00275] Furthermore, it will be easily understood that the modalities of the present invention refer to a communication network system or to an apparatus associated with it, which is configured to perform the network features and operations described above. Again, the system or device may comprise one or more computing, communication or memory components of the network infrastructure or combinations thereof, which may take various forms, such as specific servers or general-purpose computing, communication or memory devices or combinations of themselves, which are configured to provide the necessary functionality through virtualization technologies. Various methods, as disclosed in this document, can be implemented on one or more real or virtual computing devices, such as devices within a communication network control plane, devices operating on the data plane or a combination thereof. Computing devices used to implement method operations may include a processor operationally coupled to memory, the memory providing instructions for execution by the processor to perform the method as described herein.
[00276] [00276] Several modalities of the present invention use one or both of: real computational resources; and virtual computer resources. These computer resources use, at the hardware level, a set of one or more microprocessors operatively coupled to a corresponding set of memory components that include program instructions stored for execution by the microprocessors. Computing resources can be used to provide virtual computing resources at one or more levels of virtualization. For example, one or more generic computer hardware platforms can be used to supply one or more virtual computing machines. Computer hardware, such as processor resources, memory, and the like, can also be virtualized to provide resources from which other virtual computing machines are built. A set of computing resources that are allocable to provide various computing resources that, in turn, are used to carry out various computing components of a system, can be considered as providing a distributed computing system, whose internal architecture can be configured in many ways.
[00277] [00277] FIG. 22 is an example block diagram of a 2201 processing system that can be used to implement the various network functions described here. As shown in FIG. 22, processing system 2201 includes a processor 2210, working memory 2220, non-transitory storage 2230, network interface, I / O interface 2240 and, depending on the type of node, a transceiver 2260, all connected communicatively by means of bidirectional bus
[00278] [00278] According to certain modalities, all the elements represented can be used, or only a subset of the elements. In addition, the 2201 processing system may contain multiple instances of certain elements, such as multiple processors, memories or transceivers. In addition, the elements of the 2201 processing system can be coupled directly to other components without the bidirectional bus.
[00279] [00279] The memory can include any type of non-transitory memory, such as SRAM (static random access memory), dynamic random access memory (DRAM), synchronous DRAM (SDRAM), read-only memory (ROM), any combination of these or to like. The mass storage element can include any type of non-transitory storage device, such as a solid state drive, hard disk drive, magnetic disk drive, optical disk drive, USB drive, or any computer program product configured for store data and machines executable program code. According to certain modalities, the memory or mass storage registered instructions and instructions executable by the processor to carry out the functions and steps mentioned above.
[00280] [00280] Processing system 2201 can be used to implement a user plan function (UPF) or router or a CP function (PCF, SMF, etc.), as described here.
[00281] [00281] Through the descriptions of the previous modalities, the present disclosure can be implemented using only hardware or using software and a necessary universal hardware platform. Based on such understandings, the technical solution of the present disclosure can be incorporated in the form of a software product. The software product can be stored on a non-volatile or non-transitory storage medium, which can include the device memory, as described above, or stored in removable memory, such as CD-ROM (read-only memory on compact disc), memory flash, or a removable hard drive. The software product includes several instructions that allow a computer device (computer, server or network device) to perform the methods provided in the modalities of this disclosure. For example, such an execution may correspond to a simulation of logical operations, as described here. The software product may additionally or alternatively include a number of instructions that allow a computer device to perform operations to configure or program a digital logic device in accordance with the modalities of the present disclosure.
[00282] [00282] Although the present invention has been described with reference to specific characteristics and modalities thereof, it is evident that various modifications and combinations can be made without departing from the invention. The specification and drawings are therefore to be considered simply as an illustration of the invention, as defined by the appended claims, and are intended to cover any and all modifications, variations, combinations or equivalents that fall within the scope of the present invention.

权利要求:
Claims (20)
[1]
1. Application function characterized by the fact that it is configured to send a message indicating whether the user plan (UP) paths of two or more PDU sessions should be selected or re-selected together.
[2]
2. Application function characterized by the fact that it is configured to send the message, to a policy control function, PCF, indicating whether the UP paths of two or more PDU sessions should be selected or re-selected together during the selections or reselections of the UP paths, where the message also includes information indicative of the application locations, and where a common application location selected or re-selected from the application locations during the selections or reselections of the UP paths according to the policy rules associated with the message is shared by the UP paths.
[3]
3. Application function according to claim 1, characterized by the fact that the message indicates whether a common application location should be selected or re-selected for two or more PDU sessions during selections or re-selections of the UP paths .
[4]
4. Application function according to any one of claims 1 to 3, characterized by the fact that the information indicative of the application locations is expressed in the form of an access identifier to the data network, DNAI.
[5]
5. Application function according to any one of claims 1 to 4, characterized by the fact that the message also includes information to identify the traffic associated with the two or more PDU sessions, and information about the UE group to which the traffic is associated.
[6]
6. Application function according to claim 5, characterized by the fact that the information to identify the traffic comprises: a data network name (DNN) associated with the traffic, a single network slice selection assistance information (S-NSSAI) associated with traffic, traffic filter information used to identify traffic, and an application ID associated with traffic.
[7]
7. Application function according to claim 5 or 6, characterized by the fact that the information about the UE group comprises an external group identifier of the UE group.
[8]
8. Application function according to any of claims 5-7, characterized by the fact that the two or more PDU sessions are identified according to the information to identify the traffic and the information about the UE group.
[9]
9. Application function according to any of claims 1 to 8, characterized in that the message includes an indication of whether the UP paths of two or more PDU sessions should be connected via an application location or not. common selected or re-selected during selections or re-selections of the UP paths.
[10]
10. Method characterized by the fact that it comprises: sending, through an application function, a message indicating whether the user plan (UP) paths of two or more PDU sessions should be selected or re-selected together.
[11]
11. Method, according to claim 10, characterized by the fact that the sending comprises: transmitting a message carrying one or both of: said message indicating whether the user plan (UP) paths of two or more PDU sessions should be selected or re-selected together during UP path selections or re-selections, where the message also includes information indicative of application locations, where a common application location selected or re-selected from application locations during selections or re-selections of the UP paths, according to the policy rules associated with the message, is shared by the UP paths; and indication of whether or not the UP paths of the two or more sessions should be connected via a common application location selected or re-selected during the UP path selections or re-selections.
[12]
12. Method according to claim 10 or 11, characterized by the fact that the message comprises information indicating whether a common application location should be selected or re-selected for two or more PDU sessions during path selections or re-selections of UP.
[13]
13. Policy control function (PCF) characterized by the fact that it is configured to: receive a message indicating whether the user plan (UP) paths of two or more PDU sessions should be selected or re-selected together; and transmitting an instruction to a session management function (SMF) indicating that the user plan (UP) paths of two or more PDU sessions should be selected or re-selected together.
[14]
14. PCF, according to claim 13, characterized by the fact that the PCF is configured to receive the message receiving from an application function, a message indicating whether the UP paths of two or more PDU sessions should be selected or re-selected together during selections or re-selections of the UP paths, in which the message also includes information indicating the application locations; the PCF is further configured to, according to the message, generate policy rules for the two or more PDU sessions; and the PCF is configured to transmit the instruction by transmitting to the session management function (SMF) policy rules indicating that the user plan, UP, paths of two or more PDU sessions must be selected or re-selected in together, in which a common application location is selected or re- selected from application locations during UP path selections or reselections, according to policy rules, is shared by the UP paths.
[15]
15. PCF according to claim 13 or 14, characterized by the fact that the message includes an indication of whether the UP paths of two or more PDU sessions should or should not be connected via a selected common application location or re -selected during the selections or re-selections of the UP paths; or the message indicates whether a common application location should be selected or re-selected for two or more PDU sessions during the selections or new selections of the UP paths.
[16]
16. PCF according to any one of claims 13 to 15, characterized by the fact that the message further includes information to identify the traffic associated with the two or more PDU sessions, and information about the UE group to which the traffic is associated .
[17]
17. PCF, according to claim 16, characterized by the fact that the two or more PDU sessions are identified according to the information to identify the traffic and the information about the UE group.
[18]
18. Method, characterized by the fact that it comprises: receiving, by function of policy control (PCF), a message indicating whether the user plan (UP) paths of two or more PDU sessions should be selected or re- selected in set; and transmit, through the PCF, an instruction to a session management function (SMF) indicating that the user plan (UP) paths of two or more PDU sessions must be selected or re-selected together.
[19]
19. Communication system, characterized by the fact that it comprises: an application function as defined in any of claims 1 to 9; a PCF as defined in any one of claims 13-17; and a session management function (SMF) configured to: receive from a policy control function (PCF) instruction that the user plan (UP) paths of two or more designated PDU sessions must be selected or re-selected -selected together; and select or re-select the UP paths of the two or more PDU sessions based on the instruction.
[20]
20. Method, characterized by the fact that it comprises: sending, through an application function to a policy control function (PCF), a message indicating whether the user plan (UP) paths of two or more PDU sessions should be selected or re-selected together; receive the message from the PCF and transmit through the PCF an instruction to a session management function (SMF) indicating that the user plan (UP) paths of two or more PDU sessions must be selected or reselected together; and receive the instruction by SMF and select or reselect the UP paths of the two or more PDU sessions based on the instruction.

类似技术:

---

公开号 | 公开日 | 专利标题

---

BR112020009916A2|2020-11-03|method and apparatus for traffic routing and path optimization for point-to-point communications

---

CN109792458B|2021-03-02|Method and system for user plane path selection

---

KR102167343B1|2020-10-19|System and method for application-friendly protocol data unit | session management

---

US20200359293A1|2020-11-12|Systems and methods for user plane path selection, reselection, and notification of user plane changes

---

US10575220B2|2020-02-25|Session management method based on reallocation of PDU session anchor device, and device performing the session management method

---

BR112020016723A2|2020-12-15|SYSTEM AND METHOD FOR EU CONTEXT AND PDU SESSION CONTEXT MANAGEMENT

---

JP5835846B2|2015-12-24|Network system and virtual node migration method

---

CN105657081B|2019-01-18|The method, apparatus and system of DHCP service are provided

---

JP6619096B2|2019-12-11|Firewall cluster

---

WO2019100882A1|2019-05-31|Session processing method, device, and system

---

JP6599553B2|2019-10-30|Method for improving handling of at least one communication exchange between a telecommunications network and at least one user equipment, telecommunications network, user equipment, system, program and computer program product

---

JP2018509842A|2018-04-05|Method and system for establishing and managing a multi-domain virtual topology |

---

WO2013170729A1|2013-11-21|Method and system for implementing virtual network layout

---

WO2017169947A1|2017-10-05|Operation device, communication system, and update method

---

WO2016141509A1|2016-09-15|Method and system for establishing and managing multi-domain virtual tunnel |

---

US20220086703A1|2022-03-17|Session management method based on reallocation of pdu session anchor device, and device performing the session management method

---

JP2021510974A|2021-04-30|GTP tunnel for anchorless backhaul support

---

WO2015109514A1|2015-07-30|Data packet sending method, mobile router, and network device

同族专利:

---

公开号 | 公开日

---

EP3711312A4|2021-07-28|

---

WO2019096186A1|2019-05-23|

---

CN111373774B|2021-10-26|

---

CN111373774A|2020-07-03|

---

US20190158408A1|2019-05-23|

---

EP3711312A1|2020-09-23|

引用文献:

---

公开号 | 申请日 | 公开日 | 申请人 | 专利标题

---

---

US8812020B2|2010-10-15|2014-08-19|Tekelec, Inc.|Methods, systems, and computer readable media for location-based policy enhancement|

---

EP3629625B1|2011-10-14|2021-04-21|Telefonaktiebolaget LM Ericsson |Communication between mme/s4-sgsn and pcrf|

---

EP3154306B1|2014-06-25|2020-02-26|Huawei Technologies Co., Ltd.|Establishment of network connection|

---

CN106912117B|2015-12-22|2019-08-16|电信科学技术研究院|A kind of method and control plane node selecting user face nodes|

---

US10681150B2|2016-03-31|2020-06-09|Huawei Technologies Co., Ltd.|Systems and methods for management plane—control plane interaction in software defined topology management|CN110521184A|2017-03-31|2019-11-29|诺基亚通信公司|For the optimization of cloud storage related data flow|

---

US10958572B2|2017-12-13|2021-03-23|Cisco Technology, Inc.|Directing packets to service chain associated with user plane anchor|

---

US10491753B2|2018-03-27|2019-11-26|T-Mobile Usa, Inc.|Optimized policy control function mapping for application function|

---

US11113960B2|2018-03-30|2021-09-07|Intel Corporation|Intelligent traffic management for vehicle platoons|

---

CN110944361B|2018-09-21|2022-02-11|华为技术有限公司|Method and network element for load balancing|

---

US11076347B2|2018-10-01|2021-07-27|Zte Corporation|Coexistent slicing group support in network slicing|

---

US10932307B2|2018-12-31|2021-02-23|Wipro Limited|Method and device for providing wireless data communication in datacenters|

---

US10798178B2|2019-01-10|2020-10-06|Cisco Technology, Inc.|Selecting a user plane functionfor layer 2 networks|

---

US10841762B2|2019-03-05|2020-11-17|Cisco Technology, Inc.|Mobile data dynamic grouping for connected vehicle and in-vehicle networking|

---

US11160126B2|2019-05-06|2021-10-26|Comcast Cable Communications, Llc|Wireless communications for asymmetric services|

---

US10944797B2|2019-05-08|2021-03-09|Verizon Patent And Licensing Inc.|Systems and methods for next generation mobile network optimized media path selection|

---

CN110247849A|2019-05-28|2019-09-17|中国联合网络通信集团有限公司|The update method and device of URSP|

---

CN112105088A|2019-06-17|2020-12-18|华为技术有限公司|Multicast communication method, device and system|

---

US11197343B2|2019-06-18|2021-12-07|Nokia Technologies Oy|Method and apparatus for adding notifications related with user equipment multicast group and leave|

---

CN112312510A|2019-07-30|2021-02-02|华为技术有限公司|Data forwarding method, device and system|

---

WO2021031092A1|2019-08-19|2021-02-25|华为技术有限公司|Packet processing method and network device|

---

KR20210023614A|2019-08-23|2021-03-04|삼성전자주식회사|Network structure and service providing method for supporting multicast and broadcast service in mobile communication network|

---

WO2021089811A1|2019-11-08|2021-05-14|Nokia Technologies Oy|Detection and triggering for ue-to-ue p2p traffic flow routing optimization|

---

EP3843360A1|2019-12-23|2021-06-30|NTT DoCoMo, Inc.|Session management function, application function, method of operating a session management function, method of operating an application function, and non-transient computer-readable storage medium|

---

WO2021093147A1|2020-01-06|2021-05-20|Zte Corporation|Method, system and apparatus for i-smf event subscription and notification|

---

CN113543165A|2020-04-20|2021-10-22|华为技术有限公司|Communication method, device and system|

---

CN113973390A|2020-07-24|2022-01-25|华为技术有限公司|Communication method and device|

---

CN113328783A|2021-05-25|2021-08-31|广州爱浦路网络技术有限公司|Data transmission method and device in heaven-earth integrated information network and storage medium|

法律状态:
2021-12-07| B350| Update of information on the portal [chapter 15.35 patent gazette]|

优先权:

---

申请号 | 申请日 | 专利标题

---

US201762588197P| true| 2017-11-17|2017-11-17|

---

US62/588,197|2017-11-17|

---

US201862632898P| true| 2018-02-20|2018-02-20|

---

US62/632,898|2018-02-20|

---

US16/185,795|2018-11-09|

---

US16/185,795|US20190158408A1|2017-11-17|2018-11-09|Method and apparatus for traffic routing and path optimization for peer-to-peer communications|

---

PCT/CN2018/115539|WO2019096186A1|2017-11-17|2018-11-15|Method and apparatus for traffic routing and path optimization for peer-to-peer communications|

---